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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the stage 2 and stage 3 description of the non-realtime Muhimedia Messaging Service, 
MMS. Stage 2 identifies the functional capabilities and information flows needed to support the service described in 
stage 1. 

The present document includes information applicable to network operators, service providers and terminal, switch and 
database manufacturers. 

The present document contains the core functions for a non realtime Multimedia Messaging Service, MMS, which are 
sufficient to provide a basic service. 

MMS uses a number of technologies to realise the requirements of the stage 1 description (3G TS 22.140) [1]. The 
present document describes how the service requirements are realised with the selected technologies. As far as possible 
existing protocols (e.g. WAP, SMTP, ESMTP as transfer protocols; lower layers to provide push, pull, notification) and 
existing message formats (e.g. SMIL, MIME) shall be used for the realisation of the Multimedia Messaging Service. 

This specification serves as a foundation for the development of MMS. It describes a new service which has no direct 
equivalent in the previous ETSI/GSM world or in the fixed network world. In consequence readers may find that certain 
aspects are not clearly defined or open to misinterpretation. Where any such case is encountered it is essential that the 
issue is brought to the 3GPP TSG T2 standards body (see page 2 for contact information) for discussion and resolution 
in order to provide interoperable implementations. 
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Definitions and Abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply in addition to those defined in 
3GPPTR 21.905 [2] and3GPPTS 22.140 [1]: 

Abstract message: The information which is transferred between two MMS entities used to convey an MM and/or 
associated control information between these two entities. The application protocol framework and technical realisation 
of MMS service features is described in terms of abstract messages in this specification. 

Delivery Report: feedback information provided to an originator MMS User Agent by an MMS Relay/Server about the 
status of the delivery of an MM. 

External Server: A network entity/application of an external system such as Internet email, unified messaging system 
or facsimile to which MMs may be sent to and/or from which MMs may be received by an MMS User Agent via an 
MMS service provider. An External Server is connected to that MMS Service Provider via non-MMS-specific 
protocols. 
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Forwarding MMS User Agent: An MMS User Agent that is the intended recipient of an MM, that requests forwarding 
of the MM for delivery to other recipient(s) without having to first download the MM. 

Forwarded MM: An MM originally sent from a sender to an intended recipient which is then forwarded to other 
recipient(s) and to which a delivery report and/or read-reply report may refer and which may be subject to further 
forwarding. 

MM Delivery: The act of a recipient MMS Relay/Server delivering an MM to a recipient MMS User Agent. 

MM Submission: The act of an originator MMS User Agent submitting an MM to the originator MMS Relay/Server. 

MMSNA: The Multimedia Messaging Service Network Architecture encompasses all the various elements that provide 
a complete MMS to a user. 

MMSE: A collection of MMS-specific network elements under the control of a single administration. 

MMS Relay/Server: An MMS-specific network entity/application that is under the control of an MMS service 
provider. An MMS Relay/Server transfers messages, provides operations of the MMS that are specific to or required by 
the mobile environment and provides (temporary and/or persistent) storage services to the MMS. 

MMS User Agent: An application residing on a UE, an MS or an external device that performs MMS-specific 
operations on a user's behalf An MMS User Agent is not considered part of an MMSE. 

MMS VAS Applications: Applications providing Value Added Services (e.g. news service or weather forecasts) to 
MMS users. 

Original MM: An (initial) MM sent from a sender to a recipient and to which a delivery report and/or a read-reply 
report and/or a reply-MM may refer and/or which may be subject to being forwarded. 

Originator MMSE: An MMSE associated with the sender of an MM. 

Originator MMS Relay/Server: An MMS Relay/Server associated with the sender of an MM. 

Originator MMS User Agent: An MMS User Agent associated with the sender of an MM. 

Read-Reply Report: feedback information to an originator MMS User Agent by a recipient MMS User Agent about 
the status of handling/rendering of an original MM in a recipient MMS User Agent 

Recipient MMSE: An MMSE associated with the recipient of an MM. 

Recipient MMS Relay/Server: An MMS Relay/Server associated with the recipient of an MM. 

Recipient MMS User Agent: An MMS User Agent associated with the recipient of an MM. 

Reply-MM: In case of reply-charging the first reply accepted by the recipient MMS Relay/Server (after checking the 
reply charging limitations, such as the latest time of submission) is called a reply-MM. 

Transaction: A message pair sent between an MMS User Agent and MMS Relay/Server, or between MMS 
Relay/Servers. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply in addition to those defined in [1] and [2]: 

CDR Call Data Record 

DNS Domain Name System 

EMA Electronic Message Association 

E-Mail Electronic Mail 

ENUM Electronic Numbering 

FQDN Fully Qualified Domain Name 

HTTP Hypertext Transfer Protocol 

lANA Internet Assigned Numbering Authority 

IETF Internet Engineering Task Force 

IMAP4 Internet Message Access Protocol 

GW Gateway 

MIME Multipurpose Internet Mail Extensions 

MM Multimedia Message 

MMSE Multimedia Messaging Service Environment 

MMS Multimedia Messaging Service 

MMSNA Multimedia Messaging Service Network Architecture 
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MTA 


Mail Transfer Agent 


PDU 


Protocol Data Unit 


P0P3 


Post Office Protocol Version 3 


RDF 


Resource Description Format 


RFC 


Request for Comments 


SMIL 


Synchronised Multimedia Integration Language 


SMTP 


Simple Mail Transfer Protocol 


UA 


User Agent 


UAProf 


User Agent Profile 


URI 


Uniform Resource Identifiers 


VAS 


Value Added Service 


VPIM 


Voice Profile for Internet Mail 


W3C 


WWW Consortium 


WAP 


Wireless Application Protocol 


WIM 


WAP Identity Module 


WML 


Wireless Markup Language 


WSP 


WAP Session Protocol 


WTLS 


Wireless Transport Layer Security 


4 


General Architecture 


4.1 


Overview 




Figure 1 : General view of IVIIVIS provision within the different networks 

Figure 1 shows a generalised view of the Multimedia Messaging Service architecture. It shall combine different 
networks and network types and shall integrate messaging systems already existent within these networks. The terminal 
operates with the Multimedia Messaging Service Environment, MMSE. This environment may comprise 2G and 3G 
networks, 3G networks with islands of coverage within a 2G network and roamed networks. The MMSE provides all 
the necessary service elements, e.g. delivery, storage and notification functionality. These service elements may be 
located within one network or distributed across several networks or network types. 



4.2 



Involved MMS Elements 



Figure 2 shows that multimedia messaging may encompass many different network types. The basis of connectivity 
between these different networks shall be provided by the Internet protocol and its associated set of messaging 
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protocols. This approach enables messaging in 2G and 3G wireless networks to be compatible with messaging systems 
found on the Internet. 




Figure 2: IVIIVIS Architectural Elements 



MMSNA 



The Multimedia Messaging Service Network Architecture encompasses all the various elements that provide a complete 
MMS to a user (including interworking between service providers). 

MMSE 

The MMSE is a collection of MMS -specific network elements under the control of a single administration. In the case 
of roaming the visited network is considered a part of that user's MMSE. However, subscribers to another service 
provider are considered to be a part of a separate MMSE. 

MMS Relay/Server 

The MMS Relay/Server is responsible for storage and handling of incoming and outgoing messages and for the transfer 
of messages between different messaging systems. Depending on the business model, the MMS Relay/Server may be a 
single logical element or may be separated into MMS Relay and MMS Server elements. These may be distributed 
across different domains. 

The MMS Relay/Server should be able to generate charging data (Call Data Record - CDR) when receiving MMs from 
or when delivering MMs to another element of the MMSNA. 

MMS User Databases 

This element may be comprised of one or more entities that contain user related information such as subscription and 
configuration (e.g. user profile, HLR). 
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MMS User Agent 

The MMS User Agent resides on a UE, an MS or on an external device connected to a UE/MS . It is an application layer 
function that provides the users with the ability to view, compose and handle MMs (e.g. submitting, receiving, deleting 
ofMMs). 

MMS VAS Applications 

The MMS VAS Applications offer Value Added Services to MMS users. There could be several MMS VAS 
Applications included in or connected to an MMSE. MMS VAS Applications may be able to generate CDRs. 



4.3 
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Figure 3: Protocol Framework to provide IVIIVIS 

To provide implementation flexibility, integration of existing and new services together with interoperability across 
different networks and terminals, the MMS shall make use of the protocol framework outlined in figure 3. In this 
framework the MMS User Agent communicates with the MMS Relay/Server, which may communicate with External 
Servers. This MMS Relay/Server may provide convergence functionality between External Servers and MMS User 
Agents and thus enables the integration of different server types across different networks. 

Details for implementation of the MMl transfer protocol using WAP [3] or applications conforming to MExE [4] 
(e.g. Java and TCP/IP) are elaborated within this specification. The WAP implementation option is described in Annex 
B.l. Implementations based on applications using MExE may be defined in detail in future releases. Other 
implementations (e.g. using other standardised Internet protocols) are not defined in this specification in this release. 



4.4 Addressing 



MMS shall support the use of E-Mail addresses (RFC 822) [5] or MSISDN (E.164) or both to address the recipient of 
an MM. MMS may support the use of service provider specific addresses to address the recipient of an MM. In the case 
of E-Mail addresses standard internet message routing should be used. 

The usage of MSISDN for addressing a recipient in a different MMS service provider's domain shall be possible. For 
that the need of MSISDN translation to a routable address has been identified. Service provider specific addresses may 
be used to e.g. deliver messages to MMS VAS Application within one MMSE. 
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MMS connectivity across different networks (MMSEs) is provided based on Internet protocols. According to this 
approach, each MMSE should be assigned a unique domain name (e.g. mms.operatora.net). 

MMS recipient addresses provided by an MMS User Agent may be in a format of an RFC 822 routable address, e.g. E- 
Mail address, or other formats, such as E.164 or service provider specific addresses. In those cases where a non-routable 
address is used to specify a recipient and the recipient belongs to another MMSE or the recipient is outside of any 
MMSE, it is required to translate the address to an RFC 822 routable address format. It is the sender MMS 
Relay/Server's responsibility to make this mapping before routing forward the message to the recipient's MMS 
Relay/Server. 

The mapping to the correct recipient's MMS Relay/Server domain name is left for standardisation in future releases. It is 
expected that ENUM (an IETF global numbering proposal) will be used in future releases as the mechanism to map 
MSISDN numbers to RFC 822 routable addresses. In the mean time, it is expected that MMS service providers or 
network operators may use solutions for their particular needs which may include static tables or other look-up 
methods. 

MMS shall support address hiding i.e. anonymous messages where the sender's address is not shown to the recipient 
MMS User Agent. If the peer entity is not known to be an MMS Relay/Server the originator MMS Relay/Server shall 
not provide the originator address. If the peer entity is known to be an MMS Relay/Server, both the originator address 
and request of address hiding shall be forwarded to the recipient MMS Relay/Server. The recipient MMS Relay/Server 
is responsible not to show the originator address to the recipient MMS User Agent. 



5 Functional Description of Involved MMS Elements 

5.1 MMS User Agent 

5.1.1 MMS User Agent operations 

The MMS User Agent shall provide the following application layer functionalities:- 

the MM presentation; 

the presentation of notifications to the user; 

the retrieval of MMs (initiate MM delivery to the MMS User Agent). 
The MMS User Agent may provide additional application layer functionalities such as:- 

the MM composition 

the MM submission 

the signing of an MM on an end-user to end-user basis; 

the decryption and encryption of an MM on an end-user to end-user basis; 

all aspects of storing MMs on the terminal and/or USIM; 

the handling of external devices; 

the user profile management. 
This optional list of additional functionalities of the MMS User Agent is not exhaustive. 

5.1 .2 Minimum set of supported formats 

Multiple media elements shall be combined into a composite single MM using MIME multipart format as defined in 
RFC 2046 [6]. The media type of a single MM element shall be identified by its appropriate MIME type whereas the 
media format shall be indicated by its appropriate MIME subtype. 

In order to guarantee a minimum support and compatibility between multimedia messaging capable terminals, the 
following media and file formats shall be at least supported. 
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5.1.2.1 Text 

Plain text. Any character encoding (charset) that contains a subset of the logical characters in Unicode [7] shall be used 
(e.g. US-ASCII [8], ISO-8859-l[9], UTF-8[10], ShiftJIS, etc.). 

Unrecognised subtypes of "text" shall be treated as subtype "plain" as long as the MIME implementation knows how to 
handle the charset. Any other unrecognised subtype and unrecognised charset shall be treated as 
"application/octet - stream". 

In order to guarantee SMS interoperabiUty, SMS 3GPP TS 24.01 1 [11] RP-DATA RPDU encapsulation defined in 
subclause 7.3.1 shall be supported. MIME type application/x-sms shall be used for this purpose. 

NOTE: SMS MIME type shall be used as soon as the MIME registration has been completed. 

5.1.2.2 Speech 

MMS User Agents supporting media type Speech shall support AMR [12], organised in the format specified in chapters 
6.2 and 6.3 of [39]. 

5.1.2.3 Still Image 

MMS User Agents supporting media type Image shall support Baseline JPEG [17]. The usage of the Baseline JPEG 
shall follow the technical specifications and the implementation guidelines specified in 26.234 [41]. 

5.1.2.4 Video 

In order to ensure alignment with the codecs specified for Packet Switched Streaming Services [41], ITU-T H.263 
baseline [20] shall be supported in MMS User Agents that support media type Video. 

5.1 .2.5 File Format for dynamic media 

To ensure interoperability for the transport of video and associated speech/audio in an MM, the MP4 file format shall be 
supported. The usage of the MP4 file format shall follow the technical specifications and the implementation guidelines 
specified in 26.234 [41]. 

NOTE: 3GPP TS 26.234 [41] specifies a mechanism for the registration of AMR and H.263 codestreams to be 
included in MP4 files. 



5.1 .3 Additional suggested codecs 



In order to facilitate interoperability with formats widely used e.g. in the Internet community, the optional support of the 
additional following codecs is suggested: 

Media type Audio:- 

MP3 [14] 

MIDI [15] 

AAC [38] 
Media type Image: 

GIF 89a [18] 
Media type Video: 

MPEG-4 Visual Simple Profile Level [19] and [16] 

H.263 profile 3 level 10, according to [21] 
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5.2 MMS Relay/Server 



The MMS Relay/Server is responsible for storage and handling of messages. It may provide convergence functionality 
between External Servers and MMS User Agents and thus enable the integration of different server types across 
different networks. An Example can be found in Annex A. 

It should be possible to separate the MMS Relay/Server element into MMS Relay and MMS Server elements, but an 
allocation of the MMS Relay/Server functionalities to such elements is not defined in this release. 

The MMS Relay/Server is responsible for the following functions:- 

receiving and sending MM; 

enabling/disabling MMS function; 

personalising MMS based on user profile information; 

MM deletion based on user profile or filtering information; 

media type conversion; 

media format conversion; 

conversion of messages arriving at the recipient MMS Relay/Server from legacy messaging systems to MM 
format (e.g. facsimile to MM) 

conversion of MMs leaving the originator MMS Relay/Server to legacy messaging systems to the 
appropriate message format (e.g. MM to internet email) 

message content retrieval; 

MM forwarding; 

screening of MM; 

negotiation of terminal capabilities; 

checking terminal availability; 

MM notification to the MMS User Agent; 

generating call data records (CDR); 

address translation. 

address hiding 

managing the message properties on servers (e.g. voicemail or email server) integrated in the MMSE 
(consistency) 

temporary and/or persistent storage of messages 

ensuring that messages are not lost until successfully delivered to another MMSE element 

controlling the reply-charging feature of MMS 

5.3 External Servers 

Several External Servers may be included within or connected to an MMSE, e.g. E-Mail Server, SMS Server (SMSC), 
Fax. Convergence functionality between External Servers and MMS User Agents is provided by the MMS Relay/Server 
which enables the integration of different server types across different networks. Several Examples can be found in 
Annex A. 

5.4 MMS User Databases and HLR 

The MMS may have access to several User databases. These may consist of e.g. user profile database, subscription 
database, HLR. 
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These User Databases shall pro vide: - 

MMS user subscription information; 

information for the control of access to the MMS; 

information for the control of the extent of available service capability (e.g. server storage space); 

a set of rules how to handle incoming messages and their delivery; 

information of the current capabilities of the users terminal. 
The location of the User Databases and the access to them are outside the scope of this release. 



5.5 MMS VAS Applications 



The MMS VAS Applications provide value added services to the MMS users. In many ways MMS VAS Applications 
behave like a fixed MMS User Agent. However, MMS VAS Applications may provide some additional features like 
MM recall between MMS VAS Applications and MMS Relay/Server which are not available for MMS User Agents. 

This specification does not cover what kind of applications might be available and how the MMS VAS Application 
provide these services. 

MMS VAS Applications may be able to generate CDRs when receiving MMs from MMS Relay/Server and when 
submitting MMs to MMS Relay/Server. The interaction between an MMS Relay/Server and the MMS VAS Application 
should be provided through the MM7 interface, as described in subclause 7.8. 



6 IVIIVIS Service Behaviour Description 

6.1 MMS services offered 

6.1 .1 Submission of a IVI u It i media IVIessage in the originator IVIIVISE 

When a user intends to send an MM to one or several destinations the MM shall be submitted to the originator MMS 
Relay/Server. 

The support for submission of MMs is optional for MMS User Agents. The support for submission of MMs is 
mandatory for MMS Relay/Servers. 

If an MMS User Agent supports submission of MMs the MMS User Agent shall be able to: 

• Indicate the address of the MM recipient 

• Identify the MIME content type of the message. 

If a MMS User Agent supports submission of MMs the MMS User Agent may be able to: 

• Request a delivery report for the message 

• Request a read-reply report for the message 

• Provide a time stamp for the time of submission of the message 

• Set the earliest desired time of delivery for the message 

• Set the desired time of expiry for the message 

• Indicate the address of the MM originator 

• Set further message qualifications (e.g. priority, message class, subject) 

• Request the MM originator's address being hidden from the recipient MMS User Agent. 
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Upon reception of an MM from an originator MMS User Agent the originator MMS Relay/Server 

shall assign a Message Identification to the MM and immediately provide the originator MMS User Agent with this 
Message Identification 

is responsible for retaining the MM until the earliest desired time of delivery, if the optional feature of earliest time 
of delivery is supported by the originator MMS Relay/Server. If this feature is not supported then the MM is 
immediately routed forward. 

may provide a time stamp, i.e. it may also override the MMS User Agent's time stamp, 

shall insert the originator's address into the MM if not yet provided by the originator MMS User Agent 

shall pass the originator's address to the peer entity if the peer entity is known to be a MMS Relay/Server 

shall route forward the request for address hiding unaltered to the recipient MMS Relay/Server if the peer entity is 
known to be an MMS Relay/Server . 

shall pass the originator's address to the peer entity if the peer entity is not known to be an MMS Relay/Server and 
address hiding has not been requested by the originator MMS User Agent 

shall not pass the originator's address to the peer entity and should override the address provided by the originator 
MMS User Agent in the MM to an "anonymous" address if the peer entity is not known to be an MMS 
Relay/Server and address hiding has been requested by the originator MMS User Agent 

may override the address provided by the originator MMS User Agent in the MM (subject to MMS service 
provider's preferences) 

is responsible for resolving the MM recipient's address(es), 

is responsible to route the MM towards the MM recipients. 

should pass the indication whether or not a delivery report is requested unaltered when routing the MM towards the 
MM recipient(s) 

shall pass the indication whether or not a read-reply report is requested unaltered when routing the MM towards the 
MM recipient(s) 

shall pass the indication about MIME content type of the message and message qualifications (e.g. priority, 
message class, subject) unaltered when routing the MM towards the MM recipient(s) 

shall generate a delivery report indicating "indeterminate" status of the MM's delivery if a delivery report was 
requested by the originator MMS User Agent and if the peer entity the MM is routed forward to is not known by 
the originator MMS Relay/Server. 

A special case is where the recipient MMS Relay/Server is also the originator MMS Relay/Server. In this case the MM 
does not have to be routed forward. 

6.1 .2 Reception of a Multimedia Message in \he recipient MMSE 

Upon reception of an MM the recipient MMS Relay/Server 

• may verify the MM recipient's user profile(s) 

• shall store the MM at least until 

■ the associated time of expiry is reached, 

■ the MM is delivered, 

■ the recipient MMS User Agent requests the MM to be routed forward or 

■ the MM is rejected. 



£75/ 



3GPPTS 23.140 version 4.3.0 Release 4 19 ETSI TS 123 140 V4.3.0 (2001-06) 

The term "associated time of expiry " refers to either the desired time of expiry set by the originator MMS User Agent 
or an MMS Relay/Server time of expiry setting. 

• shall generate a notification to the recipient MMS User Agent. 

Incoming messages from legacy systems may be expected to be converted to MMs. 

6.1 .2.1 Multimedia Message Notification 

With the MM notification the recipient MMS User Agent shall receive a message reference that can be used for 
retrieving the MM from the recipient MMS Relay/Server. The message reference that is conveyed in a notification shall 
at least be valid throughout the message expiry period, till the successful retrieval of the MM or until the MM was 
rejected. 

With the MM notification the recipient MMS User Agent may receive additional information on the MM. 

If the originator MMS User Agent has requested address hiding the recipient MMS Relay/Server shall not include the 
originator address into the MM notification. 

In a response to the notification the MMS User Agent shall be able to 

• reject the MM or 

• retrieve the MM, either immediately or at a later time, either manually or automatically, as possibly determined by 
the operator configuration and user profile. 

6.1 .3 Retrieval of a Multimedia Message in the recipient MMSE 

The recipient MMS User Agent shall be able to request delivery of an MM from the recipient MMS Relay/Server based 
on the information received in the notification. 

Upon delivery request the recipient MMS Relay/Server 

• shall dehver the MM to the recipient MMS User Agent 

• may perform data adaptation based on user profile and/or MMS User Agent capabilities 

• shall not provide the MM originator address to the MM recipient if the originator MMS User Agent requested its 
address to be hidden from the MM recipient 

• shall provide the MM originator address to the MM recipient if the originator MMS User Agent did not request its 
address to be hidden from the MM recipient and if the MM originator address is available at the recipient MMS 
Relay/Server 

• may provide an alias or clarifying text (e.g. "anonymous address" or "unknown address") in the originator address 
field instead of providing the originator address to the recipient MMS User Agent, if the originator has requested 
address hiding or the original message does not contain the originator address 

• shall give an indication to the recipient MMS User Agent that a delivery report is requested if such a delivery report 
has been requested by the originator MMS User Agent 

• shall give an indication to the recipient MMS User Agent that a read-reply report is requested if such a read reply 
report has been requested by the originator MMS User Agent 

• shall indicate the MIME content type of the MM to the recipient MMS User Agent 

• shall provide other available message qualifications unaltered to the recipient MMS User Agent 

• shall provide the time stamp of the MM unaltered to the recipient MMS User Agent 

• shall be responsible for the storage of messages in the network until the recipient MMS User Agent becomes 
reachable (e.g. user moves back into coverage, switches MMS User Agent on) or until the MM expires. 
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• may provide the recipient MMS User Agent with a count of the number of times that the particular MM was 
forwarded, if the MM was forwarded and the counter information is available to the recipient MMS Relay/Server. 

• should provide the recipient MMS User Agent with a list of addresses of forwarding MMS User Agents for the 
MM if the MM was forwarded and the address information is available to the recipient MMS Relay/Server. 

In a response to an MM's delivery the recipient MMS User Agent may be able to 

• request a delivery report not to be generated by the MMS Relay/Server. 

6.1 .4 Forwarding of a Multimedia Message witinout prior Retrieval 

This part of the MMS service describes the mechanism by which an MMS User Agent may request the corresponding 
MMS Relay/Server, that an MM for which the MMS User Agent is the intended recipient (and is notified of the MM) 
be forwarded to other specified recipient(s) MMS User Agent(s) whose address(es) shall be specified by the forwarding 
MMS User Agent, without having to first retrieve the MM. 

The support for originating a request that a specific MM be forwarded is optional for the MMS User Agent. 

The support for forwarding an MM, in response to a request from a MMS User Agent that a specific MM be forwarded 
is optional for the MMS Relay/Server. 

The original MM is forwarded to a new recipient(s) with the forwarding MMS User Agent's address being provided but 
without additional content, and without affecting the elements of the original MM. Some additional information 
elements e.g. delivery report, read-reply report, i.e. requests for reports which are to provide feedback on the forwarded 
MM to the forwarding MMS User Agent, may be supplied. 

MM Element Forwarding, where particular elements of an MM are requested to be forwarded, is left for standardisation 
in future releases. 

If a forwarding MMS User Agent supports requesting MM forwarding the MMS User Agent shall: 

• indicate the address of the MM recipient(s). 

• provide the message reference provided in the MM Notification. 

• not generate a read-reply report to the originator MMS User Agent even if a read-reply report is requested. 
If a MMS User Agent supports requesting forwarding of MMs the forwarding MMS User Agent may: 

• Indicate the address of the Forwarding MMS User Agent (i.e. it's own address) 

• Provide a time stamp for the time of submission of the request to forward the MM 

• Set the desired time of expiry for the forwarded MM 

• Set the earliest desired time of delivery for the forwarded MM 

• Request a delivery report for the forwarded MM 

• Request a read-reply report for the forwarded MM 

Upon reception of a request from a forwarding MMS User Agent to forward an MM, the forwarding MMS 
Relay/Server 

• shall assign a Message Identification to the forwarded MM and immediately provide the forwarding MMS User 
Agent with this Message Identification 

• shall provide status information on the MM forward request to the forwarding MMS User Agent. 

• is responsible for retaining the forwarded MM until the earliest desired time of delivery, if the optional feature of 
earliest time of delivery is supported by the MMS Relay/Server of the forwarding MMS User Agent. If this feature 
is not supported then the MM is immediately routed forward. 
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may provide a time stamp for the forwarded MM, i.e. it may also override the forwarding MMS User Agent's time 
stamp, 

shall insert the forwarding MMS User Agent's address into the forwarded MM if not yet provided 

may override the address provided by the forwarding MMS User Agent in the forwarded MM (subject to MMS 
service provider' s preferences) 

is responsible for resolving the recipient's address(es) of the forwarded MM, 

is responsible to route the forwarded MM towards the MM recipients. 

shall pass the indication whether or not a delivery report is requested unaltered when routing the forwarded MM 
towards the MM recipients. 

shall pass the indication whether or not a read-reply report is requested unaltered when routing the forwarded MM 
towards the MM recipient(s) 

shall generate a delivery report indicating "indeterminate" status of the MM's delivery if a delivery report was 
requested by the forwarding MMS User Agent and if the peer entity the MM is routed forward to is not known to 
the MMS Relay/Server of the forwarding MMS User Agent. 

shall provide the recipient(s) MMS Relay/Server with a count of the number of times that the particular MM was 
forwarded. 

shall provide the recipient(s) MMS Relay/Server with a list of addresses of forwarding MMS User Agents for the 

MM. 

shall generate a delivery report to the originator MMS User Agent if a delivery report is requested. 

A special case is where the recipient MMS Relay/Server is also the forwarding MMS Relay/Server. In this case the MM 
does not have to be routed forward. 

6.1.5 Delivery Report 

The MMS Relay/Server shall support the delivery reporting service. Delivery reports shall only be generated for MMs. 

The originator MMS User Agent may be able to request a delivery report for a specific MM. 

Within an MM notification or upon MM retrieval the recipient MMS User Agent may receive an indication that a 
delivery report is requested for the MM. 

Within either a response to a notification or a response to an MM's delivery, the recipient MMS User Agent may 
request a delivery report not to be generated by the MMS Relay/Server. 

The originator MMS Relay/Server shall generate a delivery report if a delivery report has been requested by the 
originator MMS User Agent 

• upon routing forward the MM, in case the peer entity is not known by the MMS Relay/Server 

The recipient MMS Relay/Server shall generate a delivery report if a delivery report has been requested by the 
originator MMS User Agent and if the recipient MMS User Agent did not request a delivery report not to be generated 

• upon receipt of a response to a notification, in case the MM is rejected by the recipient MMS User Agent 

• upon receipt of a forwarding request, in case the MM is forwarded by the recipient MMS User Agent to other MM 
recipient(s), without prior retrieval. 

• upon receipt of a response to an MM's delivery, in case the MM is retrieved by the MM recipient 

• upon expiry of the MM, in case the MM is not rejected and not retrieved by the MM recipient before the expiry 

The originator MMS User Agent, i.e. the MMS User Agent receiving the delivery report, may match the delivery report 
to the sent MM by retaining the message identification of the sent MM and comparing it to the received delivery report, 
which shall contain the message identification of the original MM. In case of multiple MM recipients, it is necessary for 
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the originator MMS User Agent to retain the MM recipient addresses as well, to match the delivery report to the sent 
MM. 

If a delivery report has been requested by the originator MMS User Agent and if the recipient MMS User Agent did not 
request a delivery report not to be generated, the recipient MMS Relay/Server 

• shall generate the delivery report 

• shall deliver the delivery report to the originator MMS Relay/Server. 

• shall be responsible for the storage of delivery reports in the network until the originator MMS Relay/Server 
becomes reachable or until the delivery report expires 

Within the delivery report the recipient MMS Relay/Server 

• shall provide the MM originator address to the originator MMS Relay/Server. 

• shall provide the MM recipient address to the originator MMS Relay/Server. 

• shall provide the identification of the original MM for which the delivery report has been generated to the 
originator MMS Relay/Server. 

• shall provide status information how the MM was handled (e.g. expired, rejected, delivered, forwarded or 
indeterminate) to the originator MMS Relay/Server 

• shall provide a time stamp when the MM was handled to the originator MMS Relay/Server 

For each MM recipient of the original MM for which the delivery report has been generated and becomes available at 
the originator MMS Relay/Server, the originator MMS Relay/Server 

• shall deliver the delivery report to the originator MMS User Agent (i.e. the recipient MMS User Agent of the 
delivery report). 

Within the delivery report the originator MMS Relay/Server 

• shall provide the MM recipient's address to the originator MMS User Agent (the recipient MMS User Agent of the 
delivery report). 

• shall provide the identification of the original MM for which the delivery report has been generated to the 
originator MMS User Agent (the recipient MMS User Agent of the delivery report). 

• shall be responsible for the storage of delivery reports in the network until the originator MMS User Agent 
becomes reachable (e.g. user moves back into coverage, switches MMS User Agent on) or until the delivery report 
expires 



6.1.6 Read-Reply Report 



The MMS Relay/Server shall support the read-reply reporting service. Read-reply reports shall only be generated for 
MMs. 

Upon MM submission the originator MMS User Agent may be able to request a read-reply report for a specific MM. 

Upon MM retrieval the recipient MMS User Agent may receive an indication that a read-reply report is requested for 
the MM. 

After having handled/rendered the MM the recipient MMS User Agent may generate a read-reply report if requested by 
the originator MMS User Agent and if the originator MMS User Agent address is available. 

The originator MMS User Agent, i.e. the MMS User Agent receiving the read-reply report, may match the read-reply 
report to the sent MM by retaining the message identification of the sent MM and comparing it to the received read- 
reply report, which shall contain the message identification of the original MM. In case of multiple MM recipients, it is 
necessary for the originator MMS User Agent to retain the MM recipient addresses as well as to match the read-reply 
report to the sent MM. 
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If a read-reply report has been requested by the originator MMS User Agent and if the recipient MMS User Agent 
supports the read-reply feature and if the recipient allows its creation the recipient MMS User Agent shall submit the 
read-reply report to the recipient MMS Relay/Server at the earliest opportunity. 

NOTE: Since the MM recipient has the right to deny this service not receiving a read-reply report does not mean 
the message has not been rendered. 

A read-reply report: 

• shall contain the MM originator's address 

• shall contain the MM recipient's address 

• shall contain the message identification of the original MM for which the read-reply report has been generated. 

• shall provide status information how the MM was rendered (e.g. read, deleted without being read) 

• shall provide a time stamp for when the MM was rendered 

The recipient MMS User Agent shall be responsible for the storage of read-reply reports in the UE until the recipient 
MMS Relay/Server becomes reachable (subject to support of the read-reply reporting service by the recipient MMS 
User Agent and storage place being available). 

Upon reception of a read-reply report from a recipient MMS User Agent the recipient MMS Relay/Server 

may provide a time stamp for the read-reply report, i.e. it may also override the MMS User Agent's time stamp, 

shall pass the MM originator address unaltered when routing the read-reply report towards the originator MMS 
User Agent (the recipient MMS User Agent of the read reply report) 

shall insert the MM recipient's address into the read-reply report if not yet provided 

may override the address provided by the recipient MMS User Agent in the read-reply report (subject to MMS 
service provider' s preferences) 

is responsible for resolving the MM originator's address, 

is responsible to route the read-reply report towards the originator MMS User Agent of the original MM. 

A special case is where the recipient MMS Relay/Server is also the originator MMS Relay/Server. In this case the MM 
does not have to be routed forward. 



6.1 .7 Support for Streaming in MMS 



This section defines the service behaviour specific to support for streaming in MMS. The term "According to the 
normal MMS framework.." indicates those paragraphs which are not specific to streaming but described elsewhere in 
subclause 6. 

MMS supports streaming for the retrieval of MM contents (one or more MM elements). The use of streaming for the 
retrieval of MM contents is independent of the MM submission. The retrieval of MM contents to the recipient MMS 
User Agent depends on the configuration and the capability of the recipient MMS User Agent and the recipient MMS 
Relay/Server. MM contents may be either delivered as non-streaming MM elements, or made available for streaming 
retrieval. The recipient MMS Relay/Server decides whether to use streaming based on the media type and the media 
format of the subjected MM contents, capability negotiation and/or user settings/preferences. The recipient MMS 
Relay/Server may convert media types and/or formats of MM contents to make it available for streaming retrieval. If 
streaming retrieval is used, the streaming-specific protocols, codecs, presentation, session negotiation and control are 
according to [40] and [41]. 

According to the normal MMS framework, the recipient MMS Relay/Server shall generate a notification which contains 
information to enable the recipient MMS User Agent to request for the delivery of the corresponding MM 

Upon delivery request, the recipient MMS Relay/Server shall deliver a modified MM with one or several presentation 
descriptions, as one or several MM elements, in place of the corresponding streamable MM contents to the recipient 
MMS User Agent, if it has made the MM contents available for streaming retrieval. The format of the presentation 
description is as defined in [41]. MIME type of the format of the presentation description shall be used to indicate the 
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content type of the MM elements, which contain the corresponding presentation description. The presentation 
description carries all required information to initiate the streaming process by the recipient MMS User Agent in order 
to retrieve the streamable MM content. 

According to the normal MMS framework, the recipient MMS Relay/server shall base the generation of a delivery 
report on the receipt of a response to the delivery of the modified MM from the recipient MMS User Agent. 

After the successful reception of the MM, which includes the presentation description, the recipient MMS User Agent 
may initiate a streaming process to retrieve the streamable MM contents depending on the information in the 
presentation description. According to the normal MMS framework, the recipient MMS User Agent may base the 
generation of a read-reply report either on the rendering/handling of the modified MM, or on the rendering/handling of 
the streamable MM contents. 

6.1 .8 Support for Prepaid Service in MMS 

An MMS Relay/Server may support the prepaid concept. A prepaid customer may be charged for submitting or 
retrieving MMs/abstract messages. 

In the submission case the originator MMS Relay/Server may first ascertain that the originator of the MM/abstract 
message is a prepaid customer. The MMS Relay/Server may then initiate a credit check and further processing of the 
MM/abstract message is put on hold. In the case the customers credit is insufficient for submitting this particular 
MM/abstract message the originator MMS Relay/Server may reject it. The check may be based on several criteria like: 

size of the MM 

content type 

settings of information elements 

type of the abstract message 

In case an MM/abstract message can not be accepted, the originator MMS Relay/Server shall respond with an 
appropriate status value to the submit request. The MMS User Agent should bring this information to the user's 
attention. 

In case an MM/abstract message is accepted it is further processed by the MMS Relay/Server. 

In the retrieving case the recipient MMS Relay/Server may first ascertain that the recipient of the MM/abstract message 
is a prepaid customer. The MMS Relay/Server may then initiate a credit check for the particular customer. The check 
may be performed at the time the MM/abstract message arrives at the recipient MMS Relay/Server. Based on the result 
the MMS Relay/Server may reject or accept the MM/abstract message. If the MM/abstract message was accepted (with 
or without previous check) the MMS Relay/Server may perform a credit check at the time the MMS User Agent sends a 
retrieve request. The check may be based on several criteria as in the sending case. 

In case an MM/abstract message can not be retrieved because the customers account balance is too low, the recipient 
MMS Relay/Server may respond with an appropriate status value to the retrieve request. The MMS User Agent should 
bring this information to the user's attention. 

Otherwise the MM/abstract message is delivered to the MMS User Agent. 

6.1 .9 Address Hiding in MMS 

If the originator's MMS Relay/Server does not allow address hiding (anonymous messages) (e.g. legislation does not 
permit anonymous messages) the message shall be rejected upon submission and the originator's MMS Relay/Server 
shall return an error information to the originator MMS User Agent. 

In the case of originator's MMS Relay/Server rejects the message because it does not allow address hiding the rejection 
information shall be delivered in a submit response together with optional status text. 

In case the recipient MMS Relay/Server rejects the message because it does not allow address hiding and the originator 
MMS User Agent has requested a delivery report, then the recipient MMS Relay/Server shall inform the originator of 
the message rejection within the delivery report. 
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In case the recipient MMS Relay/Server rejects the message because it does not allow address hiding and the originator 
MMS User Agent has not requested a delivery report, then the originator MMS Relay/Server may inform the MM 
originator by generating a new MM which is sent back to the MM originator. 

The originator MMS Relay/Server may have the possibility to override the originator's requirement of address hiding 
without informing the originator. 

Independent of whether or not the originator's address is shown or hidden to the recipient, the originator may be able to 
ask for a delivery report to an MM and also receive the delivery report according to the normal behaviour of the MMS 
framework. 

If the originator MMS User Agent has requested both its address to be hidden and a read-reply report the originator 
MMS User Agent might not receive the read-reply report. 

If the recipient forwards the MM outside the MMSE and the peer entity is unknown to the forwarding MMS 
Relay/Server the recipient MMS Relay/Server shall not transfer the originator's address but replace it with either 
appropriate coded address or leave the originator address field blank. 



6.1 .1 Support for Reply-Charging in MMS 



The MMS User Agent may support reply-charging. If the MMS User Agent supports this feature it is expected that the 
MMS User Agent supports the following behaviour. 

The MMS Relay/Server may support reply-charging. If the MMS Relay/Server supports this feature it is expected that 
the MMS Relay/Server supports the following behaviour. 

A User of the MMS may be able to take over the charge for the sending of a reply-MM to their submitted MM from the 
recipient(s). Therefore the originator of an MM should be able to mark the MM as reply-charged. The originator's 
MMS Relay/Server could either accept the user's settings for reply-charging or not and should be able to convey 
feedback to the originator. It should be possible to take over the charge for reply-MMs from different recipients. 

The recipient should be notified that the originator is willing to pay for a reply-MM to this particular MM. However, the 
indication of reply-charging covers only the willingness to pay for a reply-MM to an original MM, not for the retrieval 
of the original MM marked as reply-charged. Both the originator and the recipient MMS Relay/Server shall be able to 
control that not more than one reply-MM per recipient is charged to the originator. The MMS User Agent may indicate 
to the user if an MM has already been replied to. 

The request for reply-charging shall not be passed on to the recipient 

• if the recipient is not known to belong to an MMSE peer entity or 

• in the case the MM is forwarded. 

NOTE: For this release the following limitations apply: Support for reply-charging in MMS is restricted to MMS 

User Agents belonging to the same MMSE, i.e. originator and recipient MMSE are identical. Reply-charging 
allows only one reply-MM per recipient, i.e. reply-charging applies to the first successful submission of an 
MM sent as a reply. Furthermore, a reply-MM is restricted to text only. These limitations may be elaborated 
further in future releases. 

In addition to the service behaviour described in previous sections the following behaviour is expected to support reply- 
charging in MMS. 

Within the submission of an MM the MM originator may indicate a willingness to pay the charge for one reply-MM per 
MM recipient. In this case the originator MMS User Agent: 

• shall indicate the sender's willingness to pay the charge for one reply-MM per MM recipient 

• may define a reply-charging limitation request (e.g. may specify the latest time of submission of the reply-MMs or 
a maximum size of reply-MMs) 

In a response to the MM submission the originator MMS Relay/Server shall inform the originator MMS User Agent 
whether or not it accepts 



£75/ 



3GPPTS 23.140 version 4.3.0 Release 4 26 ETSI TS 123 140 V4.3.0 (2001-06) 

• the originator's request for reply-charging in the original MM 

• the reply-charging limitations set by the originator MMS User Agent in the original MM 

Upon reception of an MM from an originator MMS User Agent the originator MMS Relay/Server 

• may provide reply-charging limitations, i.e. it may also override the MMS User Agent's reply-charging limitations 

• shall pass the indication whether or not a reply-MM is requested unaltered when routing the original MM towards 
the MM recipient(s) if the peer entity is known to be the same MMS Relay/Server. 

• shall pass the latest time of submission for the reply-MM unaltered when routing the original MM towards the MM 
recipient(s) if the peer entity is known to be the same MMS Relay/Server. 

If the MM recipient has requested the original MM to be forwarded to some other address the recipient MMS 
Relay/Server 

• shall not pass any information about the reply-charging request towards the addressee(s) of the forwarding request 

If reply-charging has been requested by the MM originator the recipient MMS Relay/Server should inform the recipient 
MMS User Agent with the MM notification and upon MM delivery 

• that the MM originator is willing to pay for reply-MM to this original MM. 

• It may also notify the recipient about the reply-charging limitations set by the orginator (e.g. the latest time of 
submission of a reply-MM to the original MM). 

When a user intends to send a reply-MM to the MM originator the recipient MMS User Agent (which is the originator 
MMS User Agent of the reply-MM): 

• shall mark the MM as a reply-MM. 

• shall provide the message-ID of the original MM which it replies to (if it is the reply-MM) 

• shall submit the reply-MM to the recipient MMS Relay/Server 

• may be able to indicate to the user whether this MM has already been replied to 

• may be able to indicate to the user if the reply-charging limitations can not be met 

Upon submission the recipient MMS Relay/Server 

• shall reject the reply-MM and should convey this information back to the recipient MMS User Agent if the reply- 
MM does not meet the limitations set by the originator MMS User Agent 

• shall be able to uniquely map the reply-MM to the original MM 

6.2 MMSE Addressing responsibilities 

Address parsing: 

MMS Relay/Server should parse the recipient address field provided by the originator MMS User Agent upon MM 
submission. If an error is found in the address format, an error indication should be sent back to the MMS User Agent in 
the submit response. 

Locating the recipient: 

For each recipient that appears in an MM, the MMS Relay/Server shall be able to resolve whether the recipient belongs 
to the same MMSE, another MMSE or is not known to belong to any MMSE. If the recipient belongs to the same 
MMSE, the MMS Relay/Server shall notify the recipient of the new MM as described in subclause 6.1.2. If the recipient 
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appears to belong to another MMSE, the MMS Relay/Server has to locate the external recipient's MMSE domain. If the 
recipient is not known to belong to any MMSE, the MMS Relay/Server shall perform the necessary conversion and 
route forward the message to the recipient. 

6.2.1 Address Formats on MM4 

Resolving the recipient's MMSE IP address: 

For those recipients that appear in an MM and belong to an external MMSE, the originator MMS Relay/Server has to 
send the message to the recipient's MMS Relay/Server using the protocol described in subclause 7.7. The MMS 
Relay/Server has to resolve the recipient's MMS Relay/Server domain name to an IP address, e.g. using DNS, based on 
the recipient's address. The mapping for the recipient's address to the recipient's MMS Relay/Server if the MM 
recipient belongs to another MMSE is left for standardisation in future releases. It is expected that ENUM mechanism 
will be used for this resolution. In the mean time, MMS service providers or network operators may use solutions for 
their particular needs, which may include static tables or other look-up methods. 

Re-formatting the sender's and recipient's address to FQDN format 

When delivering a message from an MMSE to another MMSE, both the sender and the recipient addresses shall be 
extended to include the FQDN to enable transport over SMTP. This FQDN format shall be used in the MM4 reference 
point. It is required that FQDN format address is used in "MAIL FROM: and "RCPT TO:" commands in SMTP, it is 
not necessary that the originator's and recipient's addresses in RFC 822 "From:" or "To:"-fields are re-formatted to 
FQDN format. 

The encoding of FQDN addressing is defined in Subclause 8.4.5.1. 

6.2.2 Address Formats on MM1 

The MMS addressing model on MMl contains three addresses: the address of the MMS Relay/Server, the address of 
the recipient and the address of the originator. The address of the MMS Relay/Server shall be the URI of the MMS 
Relay/Server given by the MMS service provider. Thus, the URI needs to be configurable in the MMS User Agent. 

The originator's and the recipient's address could be either a user's address or a user's terminal address. For this release 
the user's terminal addresses (e.g. terminal IP addresses) are not supported. The MMS User Agent's responsibility is to 
format these addresses before it submits the message to the originator MMS Relay/Server. 

The reference point MMl should support E. 164 (MSISDN) and/or RFC822 addressing, and it should support a way to 
indicate the used address type to enable future extension. The encoding of the addressing is up to the corresponding 
implementation . 

E.g. the originator MMS User Agent may specify each of the address fields in one of the following formats: 

1) RFC 822 address (FQDN) ["/TYPE= rfc822"] 

2) H-E.164 ["/TYPE= PLMN"] as [[CC] + NC] + SN 

3) Other "/TYPE=" 

The "/TYPE= " field specifies the address type. When E.164 or RFC822 formats are used the type is optional. The 
"/TYPE= " convention provides flexibility for future enhancements. 



MMSE Interfaces 



This subclause defines the Multimedia Messaging framework. The application protocol framework described by the 
means of abstract messages and the technical realisation of MMS service features are defined in subclause 8. 
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7.1 



MMS Reference Architecture 



Figure 4 shows the MMS Reference Architecture and identifies reference points within an MMSNA that are further 
described below. Abstract messages are indicated in subclause 8 that describe the logical message exchange on these 
reference points on a high-level basis. 
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Figure 4: IVIIVIS Reference Architecture 



7.2 MM1 : MMS Relay/Server - MMS User Agent 

Reference point MMl is used to submit Multimedia Messages from MMS User Agent to MMS Relay/Server, to let the 
MMS User Agent pull MMs from the MMS Relay/Server, let the MMS Relay/Server push MMs to the UA and to 
exchange notifications and delivery reports between MMS Relay/Server and MMS User Agents. 

Details for implementation of the MMl transfer protocol using WAP [3] or applications conforming to MExE [4] 
(e.g. Java and TCP/IP) are elaborated within this specification. The WAP implementation option is described in Annex 
B.l. Implementations based on applications using MExE may be defined in detail in future releases. Other 
implementations (e.g. using other standardised Internet protocols) are not defined in this specification in this release. 

7.3 MM2: MMS Relay - MMS Server 

This reference point is not specified in this release of this specification. It may be specified in a future release of this 
specification. 

7.4 MMS: MMS Relay/Server - External Servers 

Reference point MM3 is used by the MMS Relay/Server to send Multimedia Messages to and retrieve MMs from 
servers of external (legacy) messaging systems that are connected to the service provider's MMS Relay/Server. 
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This reference point is further elaborated in subclause 8.3. In addition, several examples of realisations of reference 
point MM3 between the MMS Relay/Servers and External Servers can be found in Annex A. 

7.5 MM6: MMS Relay/Server - MMS User Databases 

This reference point is outside the scope of this release of this specification. 

7.6 MMS: MMS Relay/Server - HLR 

Reference point MMS may be used to provide information to the MMS Relay/Server about the subscriber. If this 
reference point is provisioned then it shall use existing MAP operations (e.g. procedures for determining the location of 
the mobile, procedures for alerting SMS service centres). Future releases may elaborate this area further. 

In case of using SMS as the bearer for notification this reference point is not necessary. 



7.7 



MM4: Interworking of different MMSEs 



Reference point MM4 between MMS Relay/Servers belonging to different MMSEs is used to transfer messages 
between them. Interworking between MMS Relay/Servers shall be based on SMTP according to STD 10 (RFC 821) 
[22] as depicted in figure 5. 
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Figure 5: Interworking of different IVIIVISEs 

Interworking between different MMS service providers is further elaborated in subclause 8.4. 

7.8 MM7: MMS Relay/Server - MMS VAS Applications 

Reference point MM7 is used to transfer MMs from MMS Relay/Server to MMS VAS applications and to transfer 
MMs from MMS VAS applications to MMS Relay/Server. This reference point shall be based on existing protocols e.i 
SMTP or HTTP for this release of the specification. Future releases may propose a mandatory protocol and encoding 
schemes. The service provider may decide to use an encoding format in this reference point, which uses the encoding 
implementation used in the MMl reference point. 
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8 MMS Application Protocol Framework and Technical 

Realisation of MMS Service Features 

This subclause defines the appHcation protocol framework and describes the technical realisation of MMS service 
features in terms of abstract messages. The abstract messages can be categorised into transactions consisting of requests 
and responses. The labelling of the MMS abstract messages follows these conventions: 



• 



the transactions between the MMS UA and MMS Relay/Server are prefixed with "MMl"; 
the transactions between the MMS Relay/Servers are prefixed with "MM4"; 

• requests are identified with ".REQ" as a suffix; 

• responses are identified with the ".RES" suffix. 

Each abstract message carries with it certain information elements, which may vary according to the specific message. 
All messages shall carry, as information elements, a protocol version and message type, in order that the MMSE 
components may be able to properly identify and manage the message contents. 

Specific information regarding the message encapsulation, including order, possible values, and encoding are beyond 
the scope of this subclause. These details will be defined within each MMSE protocol environment. 

The mapping of abstract messages to specific protocols is not necessarily a one-to-one relationship. Depending on the 
MMS Implementation (WAP etc.), one or more abstract messages may be mapped to a single lower layer PDU, and a 
single abstract message may be mapped to multiple lower layer PDUs, if the information carried in the PDU(s) serve 
the purpose of required information in the subjected abstract message(s). 

In MMl responses that provide a status information, the status information returned has no correspondence to the Status 
information returned in MM4 responses; they are independent of each other. 

The MMl response status, which are limited by design to as small a set of values as possible, may correlate to status 
and errors occurring within the communications protocols underlying the implementation of the MM4 abstract 
messages. Similarly, the MM4 status may correlate to those occurring within the communications protocols underlying 
the implementation of the MMl abstract messages. The definition of these correlations is out of scope of this 
document, and should be provided by the MMS implementations. 

The MMS application protocol shall provide means to uniquely identify the version number and message type in each 
abstract message defined here. The order, possible values and encoding of the information elements for each abstract 
message are beyond the scope of this subclause, and shall be dictated by the protocol environment. 

The following figure shows an example abstract message flow when a multimedia message is sent from an originator 
MMS User Agent to a recipient MMS User Agent. The scope of this figure is limited to abstract messages on reference 
points MMl and MM4 only. 

Delivery reports are sent by the recipient MMS Relay/Server. Read-reply reports are sent by the recipient MMS User 
Agent. 
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Figure 6: Example Abstract lUlessage Flow 



8.1 Technical realisation of MMS on reference point MM1 
8.1 .1 Submission of IVIultimedia IVIessage 

This part of MMS service covers the submission of an MM. For sending purposes a terminal-originated MM shall 
always be submitted from the originator MMS User Agent to the corresponding MMS Relay/Server. Involved abstract 
messages are outlined in Table 1 from type and direction points of view. 

Table 1 : Abstract messages for submission of MM in MMS 



Abstract messages 


Type 


Direction 


MM1 submit.REQ 


Request 


MMS UA -> MMS Relay/Server 


MM1 submit.RES 


Response 


MMS Relay/Server -> MMS UA 



8.1 .1 .1 Normal operation 

The originator MMS User Agent shall submit a terminal-originated MM to the originator MMS Relay/Server using the 
MMl_submit.REQ, which contains MMS control information and the MM content. The MMS Relay/Server shall 
respond with an MMl_submit.RES, which provides the status of the request. The MMl_submit.RES shall 
unambiguously refer to the corresponding MMl_submit.REQ. 

Support for MMl_submit.REQ is optional for the MMS UA, support for MMl_submit.RES is mandatory for the MMS 
Relay/Server. 
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8.1 .1 .2 Abnormal Operation 

In this case the originator MMS Relay/Server shall respond with a MMl_submit.RES encapsulating a status which 
indicates the reason the multimedia message was not accepted, e.g. no subscription, corrupt message structure, service 
not available. 

If the MMS Relay/Server does not provide the MMl_submit.RES the MMS User Agent should be able to recover. 

8.1.1.3 Features 

Addressing: One or several MM recipients of a submitted MM shall be indicated in the addressing-relevant 
information field(s) of the MMl_submit.REQ. The originator of a submitted MM may be indicated in addressing- 
relevant information field(s) of the MMl_submit.REQ. The originator MMS User Agent may request to hide its identity 
from the MM recipient. 

Time stamping: The originator MMS User Agent may time stamp the MM. 

Time constraints: The originator MMS User Agent may also request an earliest desired time of delivery of the MM. 
The originator MMS User Agent may request a time of expiry for the MM. In case of reply-charging the originator 
MMS User Agent may also request a deadline for the latest time of submission of reply-MMs granted to the 
recipient(s). 

Reply-Charging: The originator MMS User Agent may indicate that the sender wants to pay for a reply-MM in the 
MMl_submit.REQ. 

Message class, priority and subject: The MM may be qualified further by adding a message class, priority and/or 
subject to the MM in the MMl_submit.REQ. Additional qualifiers may be added. 

Reporting: The originator MMS User Agent may request a delivery report for the MM. In addition, the originator 
MMS User Agent may request a read-reply report when the user has viewed the MM. 

Identification: The originator MMS Relay/Server shall always provide a message identification for an MM, which it 
has accepted for submission in the MMl_submit.RES. In case of reply-charging the MMS User Agent which submits a 
reply-MM (i.e. the MMS User Agent that received the original MM) shall provide the message-ID of the original MM 
which it replies to in the MMl_submit.REQ. 

Content Type: The MIME type of the multimedia content shall always be identified in the MMl_submit.REQ. 

Content: The originator MMS User Agent may add content in the MMl_submit.REQ. 

Request Status: The originator MMS Relay/Server shall indicate the status of the MMl_submit.REQ in the associated 
MMl_submit.RES. The reason code given in the status information element of the MMl_submit.RES may be 
supported with an explanatory text further qualifying the status. If this text is available in the status text information 
element the MMS User Agent should bring it to the user's attention. The choice of the language used in the status text 
information element is at the discretion of the MMS service provider. 
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8.1.1.4 Information Elements 



Table 2: Information elements in the MM1 submit.REQ. 



Information element 


Presence 


Description 


Recipient address 


Mandatory 


The address of the recipient MMS User Agent. Multiple 
addresses are possible. 


Content type 


Mandatory 


The content type of the MM's content. 


Sender address 


Optional 


The address of the MM originator. 


Message class 


Optional 


The class of the MM (e.g., personal, advertisement, 
information service) 


Date and time 


Optional 


The time and date of the submission of the MM (time 
stamp). 


Time of Expiry 


Optional 


The desired time of expiry for the MM or reply-MM. 


Earliest delivery time 


Optional 


The earliest desired time of delivery of the MM to the 
recipient. 


Delivery report 


Optional 


A request for delivery report. 


Reply-Charging 


Optional 


A request for reply-charging. 


Reply-Deadline 


Optional 


In case of reply-charging the latest time of submission of 
replies granted to the recipient(s). 


Priority 


Optional 


The priority (importance) of the message. 


Sender visibility 


Optional 


A request to show or hide the sender's identity when the 
message is delivered to the recipient. 


Read reply 


Optional 


A request for read reply report. 


Subject 


Optional 


The title of the whole multimedia message. 


Reply-Charging-ID 


Optional 


In case of reply-charging when the reply-MM is submitted 
within the MM1_submit.REQ this is the identification of the 
original MM that is replied to. 


Content 


Optional 


The content of the multimedia message 


Table 3: Information elements in the MM1_submit.RES. 


Information element 


Presence 


Description 


Request Status 


Mandatory 


The status of the MM submit request. 


Request Status Text 


Optional 


Description which qualifies the status of the MM submit 
request. 


Message ID 


Mandatory 


The identification of the MM given to an accepted MM. 



8.1 .2 Multimedia Message Notification 

This part of the MMS service covers the notification about MM from the recipient MMS Relay/Server to the 
corresponding recipient MMS User Agent and involving abstract messages are outUned in Table 4 from type, and 
direction points of view. 

Table 4: abstract messages for notification of MM in MMS 



Abstract message 


Type 


Direction 


MM1 notification. REQ 


Request 


MMS Relay/Server -> MMS UA 


MM1 notification. RES 


Response 


MMS UA -> MMS Relay/Server 



8.1.2.1 



Normal Operation 



Upon receiving the MMl_notification.REQ, the recipient MMS User Agent shall respond with the 
MMl_notification.RES to the recipient MMS Relay/Server to acknowledge the successful reception of the 
MM 1 _notification.REQ. 

The MMl_notification.RES shall unambiguously refer to the corresponding MMl_notification.REQ. 
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8.1.2.2 Abnormal Operation 

In this case the MMS UA shall respond with a MMl_notification.RES encapsulating a status which indicates the reason 
the notification could not be processed. If the MMS UA does not provide the MMl_notification.RES the MMS 
Relay/Server should be able to retransmit the notification at a later state. 

8.1.2.3 Features 

Addressing: The MM originator address may be provided to recipient MMS User Agent in the 
MMl_notification.REQ. 

Time constraints: The recipient MMS User Agent shall be provided a time of expiry of the MM. In case of reply- 
charging the deadline for the latest time of submission of a reply-MM should be conveyed within the 
MMl_notification.REQ. 

Reply-Charging: In case of reply-charging the MMS Relay/Server may indicate in the MMl_notification.REQ that a 
reply to the notified original MM is free of charge. 

Message class, message size and subject: The MM shall be quahfied further by adding a message class and an 
approximate size to the MM in the MMl_notification.REQ. The MM may be qualified further by adding a subject to 
the MM. Additional qualifiers may be added. 

Reporting: If the originator MMS User Agent has requested to have a delivery report, the recipient MMS Relay/Server 
may convey this information to the recipient MMS User Agent in the MMl_notification.REQ. The recipient MMS User 
Agent may indicate in the MMl_notification.RES that it would not wish a delivery report to be created. 

Identification: In case of reply-charging when a reply-MM is notified within the MMl_notification.REQ the MMS 
Relay/Server should convey the identification of the original MM replied to within the same MMl_notification.REQ. 

Message Reference: The recipient MMS Relay/Server shall always provide a reference, e.g., URI, for the MM in the 
MMl_notification.REQ. 

MM Status: The recipient MMS User Agent may indicate in the MMl_notification.RES how it intends the MM to be 
handled, e.g. the immediate rejection of the MM. 

8.1.2.4 Information Elements 

Table 5: Information elements in the MM1 notification. REQ. 



Information element 


Presence 


Description 


Message class 


Mandatory 


The class of the MM (e.g., personal, advertisement, 
information service; default = personal) 


Message size 


Mandatory 


The approximate size of the MM 


Time of expiry 


Mandatory 


The time of expiry for the MM. 


Message Reference 


Mandatory 


a reference, e.g., URI, for the MM 


Subject 


Optional 


The title of the whole MM. 


Sender address 


Optional 


The address of the MM originator. 


Delivery report 


Optional 


Request for delivery report 


Reply-Charging 


Optional 


Information that a reply to this particular original MM is free of 
charge. 


Reply-Deadline 


Optional 


In case of reply-charging the latest time of submission of a 
reply granted to the recipient. 


Reply-Charging-ID 


Optional 


The identification of the original MM replied to if this 
notification indicates a reply-MM. 
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Table 6: Information elements in the MM1 notification. RES. 



Information element 


Presence 


Description 


MM Status 


Optional 


The status of the MM's retrieval 


Report allowed 


Optional 


Request to allow or disallow the sending of a delivery report 
to the MM originator 



8.1 .3 Retrieval of Multimedia Message 

This part of MMS service covers the retrieval of an MM. For retrieval purposes an MM shall always be retrieved by the 
recipient MMS User Agent from the recipient MMS Relay/Server. Involved abstract messages are outlined in Table 7 
from type and direction points of view. 

Table 7: Abstract messages for retrieval of MM in MMS 



Abstract messages 


Type 


Direction 


MM1 retrieve. REO 


Request 


MMS UA -> MMS Relay/Server 


MM1 retrieve.RES 


Response 


MMS Relay/Server -> MMS UA 


MM1_acknowledgement.REO 


Request 


MMS UA -> MMS Relay/Server 



8.1.3.1 Normal Operation 

The recipient MMS User Agent shall issue an MMl_retrieve.REQ to the recipient MMS Relay/Server to initiate the 
retrieval process. The MMS Relay/Server shall respond with an MMl_retrieve.RES, which contains MMs control 
information and the MM content. 

After receiving the MMl_retrieve.RES, the recipient MMS User Agent shall send an MMl_acknowledgement.REQ to 
the corresponding MMS Relay/Server, if requested by the MMS Relay/Server. The MMl_acknowledgement.REQ shall 
unambiguously refer to the corresponding MMl_retrieve.RES. 

8.1.3.2 Abnormal Operation 

If the recipient MMS Relay/Server can not process the MMl_retrieve.REQ, for example due to invalid content location 
or expiration of the message, the recipient MMS Relay/Server shall respond with either an MMl_retrieve.RES or a 
lower protocol layer error message encapsulating a status which indicates the reason to the MMS User Agent the 
multimedia message was not delivered. 

If the MMS Relay/Server does not provide the MMl_retrieve.RES or the lower protocol layer error message the MMS 
User Agent should be able to recover. 



8.1.3.3 Features 

Message Reference: The recipient MMS User Agent shall always provide a reference, e.g.. 
MMl_retrieve.REQ. 



URI, for the MM in the 



Addressing: The MM originator address may be provided to the recipient MMS User Agent in the addressing-relevant 
information field of MMl_retrieve.RES. The MM originator address shall not be provided to the recipient MMS User 
Agent if the MM originator has requested her address to be hidden from the MM recipient. One or several address(es) 
of the MM recipient(s) may be provided to the recipient MMS User Agent in the addressing-relevant information 
field(s) of the MMl_retrieve.RES. 

Time stamping: The MMl_retrieve.RES shall carry the time and date of submission of the MM or the time and date of 
the forwarding of the MM. 

Time constraints: In case of reply-charging the deadline for the latest time of submission of a reply-MM shall be 
conveyed within the MMl_retrieve.RES. 

Message class, priority and subject: Information about class, priority, subject of the MM shall be included in the 
MMl_retrieve.RES according to their presence and value received at the MMS Relay/Server. Information about 
additional end-to-end qualifiers of the MM should be included in the MMl_retrieve.RES according to their presence 
and value received at the MMS Relay/Server. 
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Reporting: If the originator MMS User Agent has requested to have a read-reply report, the recipient MMS 
Relay/Server shall convey this information in the MMl_retrieve.RES. If the originator MMS User Agent has requested 
to have a delivery report, the recipient MMS Relay/Server may convey this information to the recipient MMS User 
Agent in the MMl_retrieve.RES. If a request for a delivery report is included in the MMl_retrieve.RES the recipient 
MMS User Agent shall convey the information whether it accepts or denies the sending of a delivery report to the MM 
originator in MMI_acknowledgement.REQ. If a delivery report is not requested, it is up to the recipient MMS User 
Agent to include this information in MMl_acknowledgement.REQ or not. 

Reply-Charging: In case of reply-charging the MMS Relay/Server should indicate in the MMl_retrieve.RES that a 
reply to this particular original MM is free of charge 

Identification: The MMS Relay/Server shall provide a message identification for a message, which it has accepted for 
delivery in the MMl_retrieve.RES. In case of reply-charging the MMS Relay/Server shall provide the message-ID of 
the original MM which is replied to in the MMl_retrieve.RES. 

Content Type: The type of the MM's content shall always be identified in the MMl_retrieve.RES. 

Content: The content of the multimedia message if added by the originator MMS User Agent of the MM may be 
conveyed in the MMl_retrieve.RES. 

Status: In case of normal operation the recipient MMS Relay/Server may indicate in the MMl_retrieve.RES that the 
retrieval of the MM was processed correctly. In case of abnormal operation the recipient MMS Relay/Server shall 
indicate in the MMl_retrieve.RES the reason why the multimedia message could not be retrieved. The corresponding 
reason codes should cover application level errors (e.g. 'the media format could not be converted', 'insufficient credit 
for retrieval'). Lower layer errors may be handled by corresponding protocols. 

Forward_Counter: A Counter indicating the number of times the particular MM was forwarded. 

Forwarded_by: The address of the forwarding MMS User Agent. Multiple addresses are possible. In the multiple 
address case this is a sequential list of the address(es) of the forwarding MMS User Agents who forwarded the same 
MM. 

8.1.3.4 Information Elements 

Table 8: Information elements in the MM1 retrieve.REQ . 



Information element 


Presence 


Description 


Message Reference 


Mandatory 


Location of the content of the MM to be retrieved. 
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Table 9: Information elements in the MM1 retrieve.RES 



Information element 


Presence 


Description 


Message ID 


Mandatory 


The message ID of the MM. 


Sender address 


Conditional 


The address of the originator of MM unless the originator 
MMS User Agent has requested her address to be hidden 
from the MM recipient. 


Content type 


Mandatory 


The content type of the MM's content. 


Recipient address 


Optional 


The address of the MM recipient. Multiple addresses are 
possible. 


Message class 


Optional 


The class of the message (e.g., personal, advertisement, 
information service) 


Date and time 


Mandatory 


The time and date of the submission of the MM or the time 
and date of the forwarding of the MM (time stamp) 


Delivery report 


Optional 


A request for delivery report. 


Priority 


Conditional 


The priority (importance) of the message if specified by the 
originator MMS User Agent.. 


Read reply 


Conditional 


A request for read-reply report if the originator MMS User 
Agent of the MM has requested a read-reply report. 


Subject 


Conditional 


The title of the whole multimedia message if specified by the 
originator MMS User Agent of the MM. 


Status 


Optional 


The status of the MM retrieve request. 


Status Text 


Optional 


Description which qualifies the status of the MM retrieve 
request. 


Reply-Charging 


Optional 


Information that a reply to this particular original MM is free of 
charge. 


Reply-Charging-ID 


Optional 


In case of reply-charging this is the identification of the 
original MM replied to. 


Reply-Deadline 


Optional 


In case of reply-charging the latest time of submission of a 
reply granted to the recipient. 


Forward_counter 


Conditional 


A Counter indicating the number of times the particular MM 
was forwarded. 


Forwarded_by 


Conditional 


The address of the forwarding MMS User Agent. Multiple 
addresses are possible. In the multiple address case this is a 
Sequential list of the address(es) of the forwarding MMS User 
Agents who forwarded the same MM. 


Content 


Conditional 


The content of the multimedia message if specified by the 
originator MMS User Agent of the MM. 


Table 10: Information elements in the MM1_acknowledgement.REQ . 


Information element 


Presence 


Description 


Report allowed 


Optional 


Request to allow or disallow the sending of a delivery report 
to the MM originator 



8.1 .4 Forwarding of Multimedia Message 

This part of the MMS service describes the mechanism by which a forwarding MMS User Agent can request from the 
corresponding MMS Relay/Server, that an MM for which the MMS User Agent is the intended recipient (and is notified 
of the MM) be forwarded to other specified recipient(s) MMS User Agent(s) whose address(es) shall be specified by 
the forwarding MMS User Agent, without having to first retrieve the MM. 

For forwarding purposes an MM forward request shall always be requested by the forwarding MMS User Agent from 
the forwarding MMS Relay/Server. Involved abstract messages are outlined in Table 1 1 from type and direction points 
of view. 

Table 11 : Abstract messages for forwarding of MM without prior retrieval 



Abstract messages 


Type 


Direction 


MM1 forward.REQ 


Request 


MMS UA -> MMS Relay/Server 


MM1 forward. RES 


Response 


MMS Relay/Server -> MMS UA 
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8.1.4.1 Normal operation 

The forwarding MMS User Agent shall issue an MMl_forward.REQ to the forwarding MMS Relay/Server, which 
contains MMS control information. The MMS Relay/Server shall respond with an MMl_forward.RES, which provides 
the status of the request. The MMl_forward.RES shall unambiguously refer to the corresponding MMl_forward.REQ. 
Support for MMl_forward.REQ is optional for the MMS User Agent. Support for MMl_forward.RES is optional for 
the MMS Relay/Server. 

8.1.4.2 Abnormal Operation 

In this case the MMS Relay/Server shall respond with an MMl_forward.RES encapsulating a status which indicates the 
reason the request for forwarding was not accepted, e.g. no subscription, service not available, invalid content location, 
message expired. 

If the MMS Relay/Server does not provide the MMl_forward.RES the MMS User Agent should be able to recover. 

8.1.4.3 Features 

Addressing: One or several recipients of an MM forward request shall be indicated in the addressing-relevant 
information field(s) of the MMl_forward.REQ. The forwarding MMS User Agent may be indicated in addressing- 
relevant information field(s) of the MMl_forward.REQ. 

Time stamping: The forwarding MMS User Agent may time stamp the MM. 

Time constraints: The forwarding MMS User Agent may request an earliest desired time of delivery of the MM. The 
forwarding MMS User Agent may request a time of expiry for the MM. 

Reporting: The forwarding MMS User Agent may request a delivery report for the MM. In addition, the forwarding 
MMS User Agent may request a read-reply report when the user has viewed the MM. 

Identification: The MMS Relay/Server of the forwarding MMS User Agent shall always provide a message 
identification for an MM forward request, which it has accepted for being forwarded in the MMl_forward.RES. 

Message Reference: The forwarding MMS User Agent shall always provide the reference, e.g., URI, for the MM in the 
MMl_forward.REQ which was provided in MMl_notification.REQ. 

Status: The MMS Relay/Server of the forwarding MMS User Agent shall indicate the status of the MMl_forward.REQ 
in the MMl_forward.RES. The reason code given in the status information element of the MMl_forward.RES may be 
supported with an explanatory text further qualifying the status. If this text is available in the status text information 
element the MMS User Agent should bring it to the user's attention. The choice of the language used in the status text 
information element is at the discretion of the MMS service provider. 

8.1.4.4 Information Elements 

Table 12: Information elements in the MM1 forward. REQ. 



Information element 


Presence 


Description 


Recipient address 


Mandatory 


The address of the recipient of the forwarded MM. Multiple 
addresses are possible. 


Forwarding address 


Optional 


The address of the forwarding MMS User Agent. 


Date and time 


Optional 


The time and date of the forwarding of the MM. 


Time of Expiry 


Optional 


The desired time of expiry for the forwarded MM. 


Earliest delivery time 


Optional 


The earliest desired time of delivery of the MM to the 
recipient. 


Delivery report 


Optional 


A request for delivery report for the forwarded MM. 


Read reply 


Optional 


A request for read reply report. 


Message Reference 


Mandatory 


A reference, e.g., URI, for the MM 
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Table 13: Information elements in the MM1 forward. RES. 



Information element 


Presence 


Description 


Status 


Mandatory 


The status of the MM Forward request. 


Status Text 


Optional 


Description which qualifies the status of the MM Forward 
request. 


Message ID 


Mandatory 


The identification of the MM given to an accepted MM. 



8.1.5 Delivery Report 

This part of MMS service covers the sending of delivery report from originator MMS Relay/Server to the originator 
MMS User Agent. The involved abstract message is outlined in Table 14 from type and direction points of view. 

Table 14: abstract message for sending delivery reports in MMS 



Abstract Message 


Type 


Direction 


MM1_delivery_report.REQ 


Request 


MMS Relay/Server -> MMS UA 



8.1.5.1 Normal Operation 

The originator MMS Relay/Server shall (subject to user, MMS service provider and/or operator preferences) create the 
MMl_delivery_report.REQ and send it to the originator MMS User Agent when the appropriate information for the 
creation of a delivery report is available. Support for MMl_delivery_report.REQ is optional for the MMS User Agent 
but mandatory for the MMS Relay/Server. 

8.1.5.2 Abnormal Operation 

The MMS protocol framework does not provide mechanisms to cover and handle the unsuccessful delivery of 
MMl_delivery_report.REQ. The underlying protocols shall provide reliable transport of MMl_delivery_report.REQ. 

8.1.5.3 Features 

Identification: In the MMl_delivery_report.REQ the MMS Relay/Server shall always provide the original message 
identification of the MM that the delivery report corresponds to. 

Addressing: The MM recipient address shall be provided to the originator MMS User Agent in the addressing-relevant 
information field of MMl_delivery_report.REQ. 

Time stamping: The MMl_delivery_report.REQ shall carry the time and date of handling of the MM (e.g. retrieval, 
expiry, rejection). 

MM Status: The MMl_delivery_report.REQ shall carry the status of the MM delivery, e.g. retrieved, forwarded, 
rejected, expired or indeterminate. 

8.1.5.4 Information Elements 

Table 15: Information elements in the MMIdeliveryreport.REQ. 



Information element 


Presence 


Description 


Message ID 


Mandatory 


The identification of the original MM. 


Recipient address 


Mandatory 


The address of the MM recipient of the original MM. 


Event Date 


Mandatory 


Date and time the MM was handled (retrieved, expired, 
rejected, etc.) (time stamp) 


MM Status 


Mandatory 


Status of the MM, e.g. retrieved, forwarded, expired, rejected 
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8.1.6 Read-Reply Report 

This part of MMS service covers the sending of read-reply report from the recipient MMS User Agent to the recipient 
MMS Relay/Server and the sending of read-reply report from the originator MMS Relay/Server to the originator MMS 
User Agent. The involved abstract messages are outlined in Table 16 from type and direction points of view. 

Table 16: Abstract messages for sending and receiving read-reply report in MMS 



Abstract messages 


Type 


Direction 


MM1 read reply recipient.REQ 


Request 


MMS UA -> MMS Relay/Server 


MM1 read reply originator.REQ 


Request 


MMS Relay/Server -> MMS UA 



8.1.6.1 Normal Operation 

If a read-reply report is requested for an MM, the recipient MMS User Agent may create the 
MMl_read_reply_recipient.REQ and send it to the recipient MMS Relay/Server. 

The originator MMS Relay/Server shall (subject to user, MMS service provider and/or operator preferences) create the 
MMl_read_reply_originator.REQ and send it to the originator MMS User Agent when the appropriate information for 
the creation of a read-reply report is available. 

Support for MMl_read_reply_recipient.REQ and MMl_read_reply_originator.REQ is optional for the MMS User 
Agent but mandatory for the MMS Relay/Server. 

8.1.6.2 Abnormal Operation 

The MMS protocol framework does not provide mechanisms to cover and handle the unsuccessful delivery of 
MMl_read_reply_recipient.REQ and MMl_read_reply_originator.REQ. 

8.1.6.3 Features 

Identification: In the MMl_read_reply_recipient.REQ the recipient MMS User Agent shall provide the original 
message identification of the MM that the read-reply report corresponds to. In the MMl_read_reply_originator.REQ the 
originator MMS Relay/Server shall provide the original message identification of the MM that the read-reply report 
corresponds to. 

Addressing: The MM originator address shall be provided in the addressing-relevant information field(s) of 
MMl_read_reply_recipient.REQ. The MM recipient address shall be provided in the addressing-relevant information 
field(s) of MMl_read_reply_recipient.REQ. Both, the MM recipient and MM originator addresses shall be provided in 
the addressing-relevant information field(s) of the MMl_read_reply_originator.REQ. If the MM recipient address is not 
yet provided in the MMl_read_reply_recipient.REQ the MMl_read_reply_originator.REQ shall carry the MM 
recipient address set by the recipient MMS Relay/Server. 

Time stamping: The MMl_read_reply_recipient.REQ may carry the time and date of user handling the MM depending 
on the status of the MM. The MMl_read_reply_originator.REQ shall carry the time-stamp from the corresponding 
MMl_read_reply_recipient.REQ if provided. If this time-stamp is not yet provided the 
MMl_read_reply_originator.REQ shall carry the time-stamp set by the recipient MMS Relay/Server. 

MM Status: Both the MMl_read_reply_recipient.REQ and MMl_read_reply_originator.REQ shall carry the status of 
the MM retrieval, e.g. read or without being read. 
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8.1.6.4 Information Elements 



Table 17: Information elements in the MM1_read_reply_recipient.REQ. 



Information element 


Presence 


Description 


Recipient address 


Mandatory 


Tlie address of tlie MM recipient of tlie original 
MM, i,e, the originator of the read-reply report. 


Originator address 


Mandatory 


The address of the MM originator of the original 
MM, i,e, the recipient of the read-reply report. 


IVIessage-ID 


Mandatory 


The message ID of the original MM. 


Date and Time 


Optional 


Date and time the MM was handled (read, deleted 
without being read, etc.) (time stamp) 


Status 


Mandatory 


Status of the MM, e.g. Read, Deleted without 
being read 



Table 18: Information elements in the MM1_read_reply_originator.REQ. 



Information element 


Presence 


Description 


Recipient address 


Mandatory 


The address of the MM recipient of the original 
MM, i,e, the originator of the read-reply report. 


Originator address 


Mandatory 


The address of the MM originator of the original 
MM, i,e, the recipient of the read-reply report. 


Message-ID 


Mandatory 


The message ID of the original MM. 


Date and Time 


Mandatory 


Date and time the MM was handled (read, deleted 
without being read, etc.) (time stamp) 


MM Status 


Mandatory 


Status of the MM, e.g. Read, Deleted without 
being read 



8.2 Technical realisation of IVIIVIS on reference point MM2 

This subclause may be specified further in future releases. 

8.3 Technical realisation of MMS on reference point MM3 

This subclause defines the interworking between MMS Relay/Servers and External Servers. The interworking with 
these External Servers may be based on the Internet Protocol, IP. 

Reference point MM3 should be based upon existing standards e.g. HTTP, SMTP. Several examples of realisations can 
be found in Annex A. In addition, MMS service providers or network operators may develop solutions for their 
particular needs. 

8.3.1 Sending of MMs 

For the purpose of sending an MM to an external messaging system the originator MMS Relay/Server should convert 
the MM into a format appropriate for the external messaging system. 

The originator MMS Relay/Server should use the information elements associated with the MM to define the control 
information needed for the transfer protocol in use. The originator MMS Relay/Server may use the information 
elements associated with the MM to convey these as part of the converted message. 

E.g., the originator MMS Relay/Server should use the recipient's address(es) as indicated in the corresponding MM to 
route the converted message towards its recipient(s). In addition to this, it may e.g. convey message class, priority and 
subject of the associated MM as part of the converted message. 



8.3.2 Receiving of messages 



For the purpose of receiving a message from an external messaging system the recipient MMS Relay/Server should 
convert incoming messages to the MM format in use by the recipient(s) that form part of the recipient MMS Service 
Provider's domain. 
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The recipient MMS Relay/Server may convert control information received from the External Server into appropriate 
information elements of an MM. 

E.g., the recipient MMS Relay/Server should use the MSISDNs associated with an SMS-Short Message to define the 
sender's and recipient's addresses of the MM. In addition to this, it may e.g. map a priority assigned to an incoming 
SMS-Short Message to the MM's priority. 

8.3.3 Discovery of new messages on External Servers 

For discovery of incoming messages from external messaging systems different mechanisms may be utilised, e.g.: 

• Forwarding of messages from External Server to MMS Relay/Server, based on criteria defined by the user or 
application. 

• Notification of messages from an External Server, followed by retrieval by the MMS User Agent via the MMS 
Relay/Server. 

• Periodic polling for messages on External Server, followed by retrieval by the MMS User Agent via the MMS 
Relay/Server. 

More detailed specification of these mechanisms should be further elaborated in future versions of this specification. 

8.4 Technical realisation of IVIMS on reference point MM4 

An MMSE may be able to discover a peer MMSE. This subclause defines the interworking between MMS 
Relay/Servers once the peer systems are aware of each other being an MMSE. 

Future releases may elaborate how peer MMSEs discover each other. In the mean time, it is expected that MMS service 
providers or network operators will develop solutions for their particular needs which may include static tables or other 
look-up methods. 

8.4.1 Routing Forward of a IVIultimedia IVIessage 

This part of MMS service covers the routing forward of an MM from an originator MMS Relay/Server to a recipient 
MMS Relay/Server of different MMSEs. Involved abstract messages are outlined in Table 19 from type and direction 
points of view. 

Table 19: Abstract messages for forwarding of IVIIVI in IVIIVIS 



Abstract messages 


Type 


Direction 


MM4_forward.REQ 


Request 


Originator IVIIVIS Relay/Server -> recipient IVIIVIS 
Relay/Server 


MM4_forward.RES 


Response 


Recipient MMS Relay/Server -> originator MMS 
Relay/Server 



8.4.1.1 Normal operation 

After successful discovery of its peer entity the originator MMS Relay/Server shall route an MM forward to the 
recipient MMS Relay/Server using the MM4_forward.REQ, which contains MMS control information and the MM 
content. The recipient MMS Relay/Server shall respond with a MM4_forward.RES, which provides the status of the 
request if an MM4_forward.RES was requested. 

Support for MM4_forward.REQ and MM4_for ward. RES is mandatory for the MMS Relay/Server. 

8.4.1.2 Abnormal Operation 

In this case the recipient MMS Relay/Server shall respond with a MM4_forward.RES, which includes a status that 
indicates the reason the multimedia message was not accepted, e.g. no subscription, bad address, network not reachable, 
etc., if an MM4_for ward. RES was requested. 
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8.4.1.3 Features 

Addressing: The recipient(s) of a routed forward MM shall be indicated in the addressing-relevant information field(s) 
of the MM4_forward.REQ. If the addresses of several MM recipients of the MM are associated with a single MMS 
Relay/Server then more than one MM recipient may be indicated in the addressing-relevant information field(s) of the 
MM4_forward.REQ. Addresses of all MM recipients of the MM (including those that are not associated with the MMS 
Relay/Server the MM is forwarded to) shall be conveyed in the MM4_forward.REQ for the MM recipient's 
informational purposes. 

The MM originator of a routed forward MM shall be indicated in addressing-relevant information field(s) of the 
MM4_forward.REQ. If the originator MMS User Agent requested to hide its identity from the MM recipient then the 
information about this request shall also be conveyed in the MM4_forward.REQ. 

Time stamping: The MM4_forward.REQ shall carry the time-stamp associated with the MM. 

Time constraints: If the originator MMS User Agent requested a time of expiry for the MM then this information shall 
be conveyed in the MM4_forward.REQ. 

Message class, priority and subject: If the MM is qualified further by message class, priority, subject and/or 
additional qualifiers then this information shall be conveyed in the MM4_forward.REQ. 

Reporting: If the originator MMS User Agent requested a delivery report for the MM then the information about this 
request shall be conveyed in the MM4_forward.REQ. If, in addition, the originator MMS User Agent requested a read- 
reply report then the information about this request shall be conveyed in the MM4_forward.REQ. 

Identification: The originator MMS Relay/Server shall always provide a unique message identification for an MM, 
which it routed forward to a peer MMS Relay/Server in the MM4_forward.REQ. 

Content Type: The type of the multimedia content shall always be identified in the MM4_forward.REQ. 

Acknowledgement Request: The originator MMS Relay/Server may request a MM4_forward.RES from the recipient 
MMS Relay/Server acknowledging the successful reception of the MM. 

Request Status: The recipient MMS Relay/Server shall indicate the status of the MM4_forward.REQ in the associated 
MM4_forward.RES if requested. 

Message Type: The type of message used on reference point MM4 indicating MM4_forward.REQ and 
MM4_forward.RES as such. 

Transaction Identification: If the originator MMS Relay/Server requests an MM4_forward.RES from the recipient 
MMS Relay/Server it shall provide a transaction identification within an MM4_forward.REQ. The MM4_forward.RES 
shall unambiguously refer to the corresponding MM4_forward.REQ using the same transaction identification. 

Forward_Counter: A Counter indicating the number of times the particular MM was forwarded. 

Forwarded_by: The address of the forwarding MMS User Agent. Multiple addresses are possible. In the multiple 
address case this is a Sequential list of the address(es) of the forwarding MMS User Agents who forwarded the same 
MM. 

Version: The MMS protocol shall provide unique means to identify the current version in the particular protocol 
environment. 
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8.4.1.4 Information Elements 



Table 20: Information elements in the MM4 forward. REQ. 



Information element 


Presence 


Description 


3GPP MMS Version 


Mandatory 


The MMS version of the originator MMS Relay/Server as 
defined by this specification. 


Message Type 


Mandatory 


The type of message used on reference point MM4: 
"MM4 forward. REO". 


Transaction ID 


Mandatory 


The identification of the MM4_forward.REQ/ 
MM4 forward. RES pair. 


Message ID 


Mandatory 


The identification of the MM. 


Recipient(s) address 


Mandatory 


The address(es) of the MM recipient(s). Multiple addresses 
are possible. 


Sender address 


Mandatory 


The address of the MM originator. 


Content type 


Mandatory 


The content type of the MM's content. 


Message class 


Conditional 


The class of the MM (e.g., personal, advertisement, 
information service) if specified by the originator MMS User 
Agent 


Date and time 


Mandatory 


The time and date of the submission of the Mm (time 
stamp) or the time and date of the forwarding of the MM.. 


Time of Expiry 


Conditional 


The desired time of expiry for the MM if specified by the 
originator MMS User Agent. 


Delivery report 


Conditional 


A request for delivery report if the originator MMS User 
Agent has requested a delivery report for the MM. 


Priority 


Conditional 


The priority (importance) of the message if specified by the 
originator MMS User Agent. 


Sender visibility 


Conditional 


A request to show or hide the sender's identity when the 
message is delivered to the MM recipient if the originator 
MMS User Agent has requested her address to be hidden 
from the recipient. 


Read reply 


Conditional 


A request for read reply report if the originator MMS User 
Agent has requested a read-reply report for the MM.. 


Subject 


Conditional 


The title of the whole MM if specified by the originator MMS 
User Agent. 


Acknowledgement 
Request 


Optional 


Request for MM4_forward.RES 


Forward_counter 


Conditional 


A counter indicating the number of times the particular MM 
was forwarded. 


Forwarded_by 


Conditional 


The address of the forwarding MMS User Agent. Multiple 
addresses are possible. In the multiple address case this is 
a Sequential list of the address(es) of the forwarding MMS 
User Agents who forwarded the same MM. 


Content 


Conditional 


The unaltered content of the multimedia message if 
specified by the originator MMS User Agent. 


Table 21 : Information elements in the MM4_forward.RES. 


Information element 


Presence 


Description 


3GPP MMS Version 


Mandatory 


The MMS version of the recipient MMS Relay/Server as 
defined by this specification. 


Message Type 


Mandatory 


The type of message used on reference point MM4: 
"MM4 forward.RES". 


Transaction ID 


Mandatory 


The identification of the MM4_forward.REQ/ 
MM4 forward.RES pair. 


Message ID 


Mandatory 


The Message ID of the MM which has been forwarded 
within the corresponding MM4 forward. REO 


Request Status Code 


Mandatory 


The status of the request to route forward the MM. 


Status text 


Optional 


Status text corresponding to the code 
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8.4.2 Routing Forward of a Delivery Report 

This part of MMS service covers the routing forward of a delivery report from recipient MMS Relay/Server to 
originator MMS Relay/Server. The involved abstract messages are outlined in Table 22 from type and direction points 
of view. 

Table 22: Abstract messages for routing delivery reports forward in MMS 



Abstract Message 



Type 



Direction 



Recipient MMS Relay/Server -> originator MMS Relay/Server 

("li-i/iinot/-.!- ^/l^/IC PqIo\//Cqi-\/qi- _^ i-o^iniant ^/l^/IC DqIo\//Cqi-\/qi- 



MM4_delivery_report.REQ 



Request 



Originator MMS Relay/Server -> recipient MMS Relay/Server 



MM4_delivery_report.RES 



Response 



8.4.2.1 Normal Operation 

After successful discovery of its peer entity the recipient MMS Relay/Server shall route a previously created delivery 
report forward to the originator MMS Relay/Server using the MM4_delivery_report.REQ which contains MMS control 
information only. The recipient MMS Relay/Server shall respond with a MM4_delivery_report.RES, which provides 
the status of the MM4_delivery_report.REQ if an MM4_delivery_report.RES was requested. 

Support for MM4_delivery_report.REQ and MM4_delivery_report.RES is mandatory for the MMS Relay/Server. 

8.4.2.2 Abnormal Operation 

In this case the originator MMS Relay/Server shall respond with a MM4_delivery_report.RES encapsulating a status 
which indicates the reason the delivery report was not accepted, if an MM4_delivery_report.RES was requested. 

8.4.2.3 Features 

Addressing: Both the address of the recipient (which is the MM originator) and the address of the originator (which is 
the MM recipient) of a routed forward delivery report shall be provided to the originator MMS Relay/Server in the 
addressing-relevant information field of MM4_delivery_report.REQ. 

Identification: In the MM4_delivery_report.REQ the recipient MMS Relay/Server shall always provide the original 
message identification of the MM that the delivery report corresponds to as obtained from the associated 
MM4_for ward . req . 

MM Time stamping: The MM4_delivery_report.REQ shall carry the time and date of handling of the MM (e.g. 
retrieval, expiry, rejection). 

MM Status: The MM4_delivery_report.REQ shall carry the status of the MM delivery, e.g. retrieved, rejected, expired 
or indeterminate. 

Acknowledgement Request: The recipient MMS Relay/Server may request a MM4_delivery_report.RES from the 
originator MMS Relay/Server acknowledging the successful reception of the delivery report. 

Request Status: The originator MMS Relay/Server shall indicate the status of the MM4_delivery_report.REQ in the 
associated MM4_delivery_report.RES if requested. 

Version: The MMS protocol shall provide unique means to identify the current version in the particular protocol 
environment. 

Message Type: The type of message used on reference point MM4 indicating MM4_delivery_report.REQ and 
MM4_delivery_report.RES as such. 

Transaction Identification: If the originator MMS Relay/Server requests an MM4_delivery_report.RES from the 
recipient MMS Relay/Server it shall provide a transaction identification within an MM4_delivery_report.REQ. The 
MM4_delivery_report.RES shall unambiguously refer to the corresponding MM4_delivery_report.REQ using the same 
transaction identification. 
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8.4.2.4 Information Elements 



Table 23: Information elements in the MM4_delivery_report.REQ. 



Information element 


Presence 


Description 


3GPP MMS Version 


Mandatory 


The MMS version of the recipient MMS Relay/Server as 
defined by this specification. 


Message Type 


Mandatory 


The type of message used on reference point MM4: " 
MM4 delivery report. REO". 


Transaction ID 


Mandatory 


The identification of the MM4_delivery_report.REQ/ 
MM4 delivery report. RES pair. 


MM Message ID 


Mandatory 


The identification of the original MM. 


Recipient address 


Mandatory 


The address of the MM recipient of the original MM. 


Sender address 


Mandatory 


The address of the MM originator of the original MM. 


MM Date and time 


Mandatory 


Date and time the MM was handled (retrieved, expired, 
rejected, etc.) 


Acl<nowledgement 
Request 


Optional 


Request for MM4_delivery_report.RES 


MM Status Code 


Mandatory 


Status of the MM, e.g. retrieved, expired, rejected 


Status text 


Optional 


Status text corresponding to the Status code 



Table 24: Information elements in the MM4_delivery_report.RES. 



Information element 


Presence 


Description 


3GPP MMS Version 


Mandatory 


The MMS version of the recipient MMS Relay/Server as 
defined by this specification. 


Message Type 


Mandatory 


The type of message used on reference point MM4: " 
MM4 delivery report. RES". 


Transaction ID 


Mandatory 


The identification of the MM4_delivery_report.REQ/ 
MM4 delivery report. RES pair. 


Message ID 


Mandatory 


The Message ID of the MM which caused the delivery report 


Request Status Code 


Mandatory 


The status of the associated MM4 delivery report.REQ. 


Status text 


Optional 


The text explanation corresponding to the Status code 



8.4.3 Routing Forward of a Read-Reply Report 

This part of MMS service covers the routing forward of a read-reply report from the recipient MMS Relay/Server to the 
originator MMS Relay/Server. The involved abstract messages are outlined in Table 25 from type and direction points 
of view. 



Table 25: Abstract messages for sending and receiving read-reply reports in MMS 



Abstract messages 



Type 



Direction 



Recipient MMS Relay/Server -> originator MMS Relay/Server 



MM4_read_reply.REQ 



Request 



Originator MMS Relay/Server -> recipient MMS Relay/Server 



MM4_read_reply.RES 



Response 



8.4.3.1 Normal Operation 

After successful discovery of its peer entity the recipient MMS Relay/Server shall route a read-reply report forward, 
that has been previously submitted by the recipient MMS User Agent, to the originator MMS Relay/Server using the 
MM4_read_reply_report.REQ which contains MMS control information only. The recipient MMS Relay/Server shall 
respond with a MM4_read_reply_report.RES, which provides the status of the MM4_read_reply_report.REQ if an 
MM4_read_reply_report.RES was requested. 

Support for MM4_read_reply_report.REQ and MM4_read_reply_report.RES is mandatory for the MMS Relay/Server. 

8.4.3.2 Abnormal Operation 

In this case the originator MMS Relay/Server shall respond with a MM4_read_reply_report.RES encapsulating a status 
which indicates the reason the read-reply report was not accepted, if an MM4_read_reply_report.RES was requested. 
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8.4.3.3 Features 

Addressing: Both, the address of the recipient (which is the MM originator) and the address of the originator (which is 
the MM recipient) of a routed forward read-reply report shall be provided to the originator MMS Relay/Server in the 
addressing-relevant information field of MM4_read_reply_report.REQ. 

Identification: In the MM4_read_reply_report.REQ the recipient MMS Relay/Server shall always provide the original 
message identification of the MM that the read-reply report corresponds to as obtained from the associated 
MM4_for ward .req . 

MM Time Stamping: The MM4_read_reply_report.REQ shall carry the time-stamp associated with the read-reply 
report. 

MM Status: The MM4_read_reply_report.REQ shall carry the status of the MM retrieval, e.g. read or without being 
read. 

Acknowledgement Request: The recipient MMS Relay/Server may request a MM4_read_reply_report.RES from the 
originator MMS Relay/Server acknowledging the successful reception of the read-reply report. 

Request Status: The originator MMS Relay/Server shall indicate the status of the MM4_read_reply.REQ in the 
associated MM4_read_reply.RES if requested. 

Version: The MMS protocol shall provide unique means to identify the current version in the particular protocol 
environment. 

Message Type: The type of message used on reference point MM4 indicating MM4_read_reply.REQ and 
MM4_read_reply.RES as such. 

Transaction Identification: If the originator MMS Relay/Server requests an MM4_read_reply_report.RES from the 
recipient MMS Relay/Server it shall provide a transaction identification within an MM4_read_reply_report.REQ. The 
MM4_read_reply_report.RES shall unambiguously refer to the corresponding MM4_read_reply_report.REQ using the 
same transaction identification. 

8.4.3.4 Information Elements 

Table 26: Information elements in the MM4_read_reply_report.REQ. 



Information element 


Presence 


Description 


3GPP MMS Version 


Mandatory 


The MMS version of the recipient MMS 
Relay/Server as defined by this specification. 


Message Type 


Mandatory 


The type of message used on reference point 
MM4: "MM4 read reply report.REQ". 


Transaction ID 


Mandatory 


The identification of the 
MM4_read_reply_report.REO/ 
MM4 read reply report. RES pair. 


Recipient address 


Mandatory 


The address of the MM recipient of the original 
MM, i.e. the originator of the read-reply report. 


Sender address 


Mandatory 


The address of the MM originator of the original 
MM, i.e. the recipient of the read-reply report. 


Message-ID 


Mandatory 


The message ID of the original MM. 


Date and time 


Mandatory 


Date and time the MM was handled (read, 
deleted without being read, etc.) (time stamp) 


Acl<nowledgement Request 


Optional 


Request for MM4 delivery report. RES 


MM Status Code 


Mandatory 


Status of the MM, e.g. Read, Deleted without 
being read 


Status text 


Optional 


The text explanation corresponding to the Status 
code 
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Table 27: Information elements in the MM4_read_reply_report.RES. 



Information element 


Presence 


Description 


3GPP MMS Version 


Mandatory 


The MMS version of the recipient MMS 
Relay/Server as defined by this specification. 


MM Message Type 


Mandatory 


The type of message used on reference point 
MM4: "MM4 read reply report. RES". 


Transaction ID 


Mandatory 


The identification of the 
MM4_read_reply_report.REQ/ 
MM4 read reply report. RES pair. 


Request Status Code 


Mandatory 


The status of the associated 
MM4 read reply report. REQ. 


Status text 


Optional 


The textual explanation for the Status code 



8.4.4 Message format on MM4 



All elements of an MM shall be included within a single SMTP "mail" message which shall be organised as MIME type 
application/multipart. All MM elements shall be of standard MIME content types. In addition to the MM elements this 
SMTP "mail" message should reflect all MMS information elements according to the definitions in subclauses 6 and 
8.4. 

All other MMS -related messages, such as delivery reports, read-reply reports, transfer acknowledgements shall each be 
transferred as a single SMTP "mail" message which shall be organised as MIME type text/plain. This SMTP "mail" 
message should reflect all MMS information elements as defined above. 

8.4.4.1 Message header fields 

MMS information elements should be reflected as "header fields" according to STD 1 1 in the SMTP "mail" message. 
See RFC 1327 [53] for a detailed description of the X.400 header to STD 11 headers mappings. Some of the mappings 
are context dependent. 

For those information elements that cannot be mapped to standard STD 1 1 "header fields" the "X-" extensions 
mechanism shall be used with an "X-MMS-" prefix. 

The mapping of information elements to commonly used (RFC 1327) [53] or standard STD 11 "header fields" is shown 
in following tables. 

8.4.4.2 MM4_Forward.REQ Header Mappings 

The MM4 Forward request header mappings are detailed below. 
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Table 28: MM4_Forward.REQ Information Elements to 
STD 11 Header Mappings 



Information element 


STD 11 Headers 


3GPP MMS Version 


X-Mms-3GPP-MMS-Version: 


Message Type 


X-Mms-Message-Type: 


Transaction ID 


X-IVIms-Transaction-ID: 


IVIessage ID 


X-IVIms-Message-ID: 


Recipient(s) address 


To:, CC: 


Sender address 


From: 


Content type 


Content-Type: 


IVIessage class 


X-IVIms-Message-Class: 


Date and time 


Date: 


Time of Expiry 


X-IVIms-Expiry: 


Delivery report 


X-IVIms-Delivery-Report: 


Priority 


X-IVIms-Priority: 


Sender visibility 


X-IVIms-Sender-Visibility: 


Read reply 


X-IVIms-Read-Reply: 


Subject 


Subject: 


Acknowledgement Request 


X-Mms-Ack-Request: 


Content 


<message body> 


- 


Sender: 


- 


Message-ID: 



The table above indicates the mappings from MM4_Forward.REQ information elements to the corresponding STD 11 
headers. 

The MM Message-ID is not directly mapped to a corresponding STD 1 1 [5] "Message-ID:" header. Each STD 1 1 
message must have a unique message id, which is carried in the "Message-ID:" header. 

Content-type maps directly since both are defined as being MIME content types as specified in RFC 2046 [6]. 

The STD 1 1 "From:" header is determined by the mail user agent, or, in this case, the MMS User Agent. This 
corresponds to the MM "Sender address", as set by the MMS User Agent or MMS Relay/Server. 

STD 1 1 messages are required to have a Sender: header that indicates the originator address (as determined by the 
SMTP "MAIL From" command). 

8.4.4.3 MM4_Forward.RES Header Mappings 

The MM4 Forward response information element mappings are detailed in the table below. 

The transmission of the Forward Response from the recipient MMS Relay/Server requires a properly addressed STD 1 1 
message. While the addressing of the MM4_Forward.REQ is clearly that of the intended recipients and originator, the 
MM4_For ward. RES addressing is related to neither the recipients nor the originator of the original MM. Instead, the 
MM4_Forward.RES addressing is based on special systems addresses. MMS Service Provider should configure 
appropriate system addresses which will be used as both the recipient and originator of these administrative messages. 
It is suggested that the administrative addressing be based on the pattern: 

system-userQmms-relay-host . mmse- domain . 
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Table 29: MM4_Forward.RES Information Elements to 
STD 11 Header Mappings 



Information element 


STD Header 


3GPP MMS Version 


X-Mms-3GPP-MMS-Version: 


Message Type 


X-IVIms-IVIessage-Type: 


Transaction ID 


X-IVIms-Transaction-ID: 


IVIessage ID 


X-IVIms-IVIessage-ID: 


Request Status Code 


X-IVIms-Request-Status-Code: 


Status text 


X-IVIms-Status-Text: 


- 


Sender: 


- 


To: 


- 


Message-ID: 


- 


Date: 



The Sender: and To: headers contain system addresses as described above, and do not map to MM4_Forward.RES 
information elements. The STD 1 1 message requires a Date: header, but there currently is no corresponding 
MM4_Forward.RES information element. 

8.4.4.4 MM4_Delivery_report.REQ Header Mappings 

The mappings of the MM4_Delivery_report.REQ information elements to STD 1 1 headers is detailed in the table 
below. 

Table 30: MM4_Delivery_report.REQ Information Elements to 
STD 11 Header Mappings 



Information element 


STD 11 Header 


3GPP MMS Version 


X-Mms-3GPP-MMS-Version: 


Message Type 


X-Mms-Message-Type: 


Transaction ID 


X-Mms-Transaction-ID: 


MM Message ID 


X-Mms-Message-ID: 


Recipient address 


From: 


Sender address 


To: 


MM Date and time 


Date: 


Acl<nowledgement Request 


X-Mms-Acl<-Request: 


MM Status Code 


X-Mms-MM-Status-Code: 


Status Text 


X-Mms-Status-text: 


- 


Sender: 


- 


Message-ID: 



The meaning of Recipient address is that of the original MM, from whose MMS User Agent this Delivery -report is 
being generated. The meaning of Sender address is that of the original MM, to whom the Delivery-report is being sent. 

The value of the STD 1 1 Sender: header is a system administration address, to which the corresponding response will 
be sent. 

The Sender: header value is automatically set to the system address of the MMS Relay/Server. 

The Message-ID: value is automatically generated by the MMS Relay/Server, in conformance to STD 11 [5]. 

The other header mappings from information elements are similar to those already described above. 

8.4.4.5 MM4_Delivery_report.RES Header Mappings 

The mappings of the M4_Delivery_report.RES information elements to STD 1 1 headers is detailed in the table below. 
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Table 31 : MM4_Delivery_report.RES Information Elements 
to STD 11 Header Mappings 



Information element 


STD 1 1 Header 


3GPP MMS Version 


X-Mms-3GPP-MMS-Version: 


MM Message Type 


X-Mms-Message-Type: 


Transaction ID 


X-Mms-Transaction-I D : 


Message ID 


X-Mms-Message-ID: 


Request Status Code 


X-Mms-Request-Status-Code: 


Status text 


X-Mms-Status-Text: 


- 


Sender: 


- 


To: 


- 


Message-ID: 


- 


Date: 



The Sender: header value is automatically set to the system address of the MMS Relay/Server that is replying to the 
MM4_Delivery_report.REQ. 

The To: header value of the MM4_Delivery_report.RES abstract message is obtained from the Sender: header value of 
the corresponding MM4_Delivery_report.REQ. 

The Date and Message-ID headers, which have no corresponding MM4_Forward.RES information attributes, are 
automatically provided values by the MMS Relay/Server. 

8.4.4.6 MM4_Read_reply_report.REQ Header Mappings 

The mappings of the MM4_Read_reply_report.REQ information elements to STD 1 1 headers is detailed in the table 
below. 

Table 32: MM4_Read_reply_report.REQ Information Elements 
to STD 11 Header Mappings 



Information element 


STD 1 1 Header 


3GPP MMS Version 


X-Mms-3GPP-MMS-Version: 


Message Type 


X-Mms-Message-Type: 


Transaction ID 


X-Mms-Transaction-ID: 


Recipient address 


From: 


Sender address 


To: 


Message-ID 


X-Mms-Message-ID: 


Date and time 


Date: 


Acknowledgement Request 


X-Mms-Ack-Request: 


MM Status Code 


X-Mms-MM-Status-Code: 


Status text 


X-Mms-Status-Text: 


- 


Sender: 


- 


Message-ID: 


- 


Date: 



The meaning of Recipient address is that of the original MM, from whose MMS User Agent this Read-reply-report is 
being generated. The meaning of Sender address is that of the original MM, to whom the Read-reply-report is being 
sent. 

The value of the Sender: header is a system address, to which the corresponding MM4_Read_reply_report.RES shall be 
sent. 

The Message-ID:, and Date: headers, which have no corresponding information attribute in the 
MM4_Read_reply_report.REQ, are automatically provided appropriate values by the MMS Relay/Server. 

8.4.4.7 MM4_Read_reply_report.RES Header Mappings 

The mappings of the MM4_Read_reply_report.RES information elements to STD 1 1 headers is detailed in the table 
below. 
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Table 33: MM4_Read_reply_report.RES Information Elements 
to STD 11 Header Mappings 



Information element 


STD 11 Header 


3GPP MMS Version 


X-Mms-3GPP-MMS-Version: 


MM Message Type 


X-Mms-Message-Type: 


Transaction ID 


X-Mms-Transaction-I D : 


Request Status Code 


X-Mms-Request-Status-Code: 


Status text 


X-Mms-Status-Text: 


- 


Sender: 


- 


To: 


- 


Message-ID: 


- 


Date: 



The Sender: header value shall be the system address of the MMS Relay/Server that is replying to the 
MM4_Delivery_report.REQ. 

The To: header value of the MM4_Delivery_report.RES abstract message shall be obtained from the corresponding 
MM4_Delivery_report.REQ Sender: header value. 

The Date: and Message-ID: headers, which do not have corresponding information elements, shall be provided 
appropriate values automatically by the MMS Server/Relay. 



8.4.4.8 Header Field Value Range 

MMS information elements that are mapped to standard STD 11 "header fields", i.e. which do not have an "X-MMS-" 
prefix, should be used according to [5]. 

The rest of the header definitions used in this section, including the mechanisms and pre-defined tokens, are described 
in an augmented Backus-Naur Form (BNF) defined in [48], similar to that used by RFC 822 [5]. Implementors will 
need to be familiar with the notation in order to understand these definitions. 

For the residual MMS information elements the following applies: 
X-Mms-3GPP-MMS-Version: 

3GPP-MMS-Version = "X-Mms-3GPP-MMS-Version" ":" 1*DIGIT "." 1*DIGIT "." 

1*DIGIT 

Note that the numbers MUST be treated as separate integers and that each may be incremented higher than a single 
digit. Thus, 2.1.4 is a lower version than 2.1.13, which in turn is lower than 2.3.0 Leading zeros shall be ignored by 
recipient MMS Relay/Server and shall NOT be sent. The version is according to the version of this specification 
(see also subclause "Foreword"). 

X-Mms-Message-Type: 

Message-type = "X-Mms-Message-Type" ":" ( "MM4_f orward. REQ" 

"MM4_forward.RES" | "MM4_delivery_report . REQ" | "MM4_delivery_report . RES" | 
"MM4_read_reply_report .REQ" | "MM4_read_reply_report . RES" ) 

X-Mms-Transaction-Id : 

Transaction-id = "X-Mms-Transaction-ID" ":" quoted-string 
X-Mms-Message-Id : 

Message-id = "X-Mms-Message-ID" ":" quoted-string 
X-Mms-Message-Class: 

Message-class = "X-Mms-Message-Class" ":" ( Class-identifier 



quoted-string 



Class-identifier = "Personal" 1 "Advertisement" 1 "Informational" 1 "Auto" 
X-Mms-Expiry: 
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Expiry-value = "X-Mms-Expiry" ":" ( HTTP-date | delta-seconds ) 
X-Mms-Delivery-Report: 

Delivery-report = "X-Mms-Delivery-Report" ":" ( "Yes" | "No" ) 
X-Mms-Priority: 

Priority = "X-Mms-Priority" ":" ( "Low" | "Normal" | "High" ) 
X-Mms-Sender- Visibility: 

Sender-visibility = "X-Mms-Sender-Visibility" ":" ( "Hide" | "Show" ) 
X-Mms-Read-Reply: 

Read-reply = "X-Mms-Read-Reply" ":" ( "Yes" | "No" ) 
X-Mms-Ack- Request: 

Ack-Request = "X-Mms-Ack-Request " ":" ( "Yes" | "No" ) 

X-Mms-Request-Status-Code: 

Request-Status-Code = "X-Mms-Request-Status-Code" ":" ( "Ok" | "Error- 
unspecified" I "Error-service-denied" | "Error-message-format-corrupt" 
"Error-sending-address-unresolved" | "Error-message-not-found" | "Error- 
network-problem" I "Error-content-not-accepted" | "Error-unsupported- 
message" ) 

X-Mms-MM-Status-Code: 

MM-Status-Code = "X-Mms-MM-Status-Code" ":" ( "Expired" | "Retrieved" | 
"Rejected" | "Deferred" | "Intermediate" | "Forwarded" | "Unrecognised" ) 

8.4.4.9 Message Encoding on MM4 

The SMTP "mail" message shall be encoded according to STD 1 1 [5]. 

8.4.5 Message Transfer Protocol on MM4 

Interworking between different MMSEs shall be based on SMTP according to STD 10 [22] as depicted in figure 5. 

The originator MMS Relay/Server should use an SMTP connection to transfer MMs/abstract messages. The originator 
MMS Relay/Server should use the sender's address as indicated in the corresponding MM/abstract message in the 
SMTP "MAIL FROM:" command (subject to the sender's visibility) and should use the recipient's address(es) as 
indicated in the corresponding MM/abstract message in the SMTP "RCPT TO:" command. The originator MMS 
Relay/Server should use SMTP "DATA" command to transfer the message. 

Private agreements may utilise additional connection and security (e.g. IPSec) methods. Such methods are out of the 
scope of standardisation for this release. 

8.4.5.1 Address Encoding 

In the case where E.164 addressing is used and the address resolution returns the domain of the recipient MMSE, the 
addresses shall be encoded in the following way: 

SMTP protocol level: 

SMTP-address = MMS-address "@" domain 

MMS-address = "+" E.164 "/TYPE=PLMN" 

E.164 = 1*DIGIT 

domain = dom-f ragment * ( " . " dom-f ragment ) 

dom-fragment = ( ALPHA | DIGIT ) *( ALPHA | DIGIT | "-" ) 
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Example: 

If the originator's address was an E.164 address, the address fields used in RCPT shall be converted to the following 
format by the sender's MMS Relay/Server: 

+E.164/TYPE=PLMN@recipient-mmse 

where recipient-mmse is a FQDN of the recipient's MMS Relay/Server, e.g. 

+358401234567/TYPE=PLMN@mmse.sonera.net 

SMTP commands: 

SMTP commands should be then used in the following way: 

MAIL FROM: SMTP -address 

RCPT TO: SMTP-address 

DATA 

X-MMS-3GPP-MMS-version : 4.2.0 

X-MMS-Message-Type : MM4_forward . REQ 

X-MMS-Transaction-ID : "ABCDEFGHIJ012345 6789" 

X-MMS-Message-ID : "originator-mmse/originator-username/12345 6789" 

Date: Wed, 16 May 2001 10:35:00 +0800 

From: MMS -address 

To: MMS-address 

Subject: Greetings from Greece 

Content-Type : text /plain 



Hi, ... 



NOTE: In the example above the "X-MMS-3GPP-MMS-version" header may not refer to the current version of 
this specification. 

8.5 Technical realisation of MMS on reference point MMS 

This subclause may be specified further in future releases. 

8.6 Technical realisation of MMS on reference point MM6 

This reference point is outside the scope of this release of this specification. 

8.7 Technical realisation of MMS on reference point MM7 

This subclause may be specified further in future releases. 
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Annex A (informative): 

Examples of IVIIVIS architectural implementations 



A.1 Introduction 



This informative annex is intended to provide architectural examples based on the general architecture as outlined in 
clause 4 to show implementations for different business models. The focus is upon the various MMS Relay - MMS 
Server and MMS Relay/Server - External Server scenarios, whereas the MMS Relay/Server - MMS User Agent 
interface is assumed to be as stated in subclause 7.2. Each of the following subsubclauses provides only one possible 
scenario, however a combination could be feasible. Please note that each functional element should be understood as a 
logical entity and may be combined due to implementation reasons. 



A.2 Example of combined MMS-Relay/Server 

This scenario shows the case where the two logical entities, MMS Relay and MMS Server, are combined into a single 
physical entity. 





Message 
- ^^ Store 



MMS 
Relay/Server 



Figure A.I : Example of combined IVIIVIS-Relay/Server 
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A.3 Example of non-combined M MS- Re I ay and 
MMS-Server 
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Figure A.2: Example of non-combined IVIIUIS-Relay and IVIIUIS-Server 

For the transfer of messages between an MMS-Relay and an MMS-Server the use of SMTP and POP3[34]/IMAP4[35] 
or HTTP as illustrated in Figure A.2 is identified as appropriate. 

If the protocol is SMTP for up- and download of messages to the server, then it may be identical to the one used 
between different MMS Relay/Servers as specified in the subclause 7.7. 



A.4 Example of MMS interaction with T.30 Facsimile 
Services 




MMS 

Relay/ 

Server 



Message 
~^—^ Store 




ITU-T.30 
Fax 



ITU-T.37 

Fax 
Gateway 



Figure A.3: Example of MMS interaction with Facsimile Services based on ITU-T.37 

For the transfer of facsimile data via store-and-forward mechanisms ITU-T.37 [31] procedures have been standardised. 
These are identified as appropriate in the MMSE for the interworking with T.30 [32] facsimile services. What the 
relevant MMSE parts are supposed to look like for a T.37 approach is depicted in figure A.3. The MMS Relay/Server 
interfaces with a T.37 Fax Gateway. For the Gateway's communication with the MMS Relay /Server the appropriate 
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protocol is SMTP. I.e., the protocol to be used on the interface between MMS -Relay/Server and the Fax GW is identical 
to the one used between different MMS Relay/Servers as specified in subclause 7.7. 

Towards the PSTN the Fax-GW terminates the T.30 facsimile protocol. Mobile terminated fax data will be converted 
into TIFF[36] image format and forwarded to the MMS Relay/Server as an attachment in an IETF internet email. In 
case of mobile originated fax messages the Fax-GW receives a written email provided with the receiver's fax number 
from the MMS Relay/Server. Depending on the functions of the Fax-GW this email may contain plain text only or 
additional attachments, too. Although T.37 requires only TIFF format support there are Fax-GWs out on the market that 
permit many different formats to be included. 



A.5 Example of MMS interaction with 2G/3G Voice 
Mailboxes 

MMS interaction with voice mailbox systems should be performed on a non-realtime basis. Figure A.4 illustrates an 
example architecture for the incorporation of voice mailboxes. 

today's real-time over-the-air 
access of 2G/3G voice mailbox 




MMS 

Relay/ 

Server 



SMTP 
(VPIM 
profile) 




2G/3G 

voice 

mailbox 



Figure A.4: First Example of IVIIVIS interaction with 2G/3G Voice IVIailbox based on VPIIVI 

The 'Voice Profile for Internet Mail Version 2, 'VPIMv2, provides format extensions for MIME supporting the 
transmission of voice messages over standard Internet E-Mail systems. The VPIM concept was developed by the 
Electronic Messaging Association (EMA). After VPIMv2 had been reviewed by the IETF it became RFC 2421 [33]. 

The VPIM specification allows voice records to be MIME encapsulated and sent as Internet mail attachments via SMTP 
or retrieved as Internet mail attachments via POP3 [34] or IMAP4[35]. The MIME type used for voice messages is 
"audio/*". 

For the interaction of MMS with voice mailboxes, the voice mailbox may forward received voice records as VPIM 
messages via SMTP to the MMS Relay/Server. This implies that voice messages' download is always done via the 
MMS service. In this case the protocol to be used on the interface between MMS-Relay/Server and the voice mailbox is 
SMTP and thus identical to the one used between different MMS Relay/Servers as specified in subclause 7.7. 

Alternatively, the MMS Relay/Server may poll the voice mailbox via POP3 or IMAP4 for new messages received. 
Messages the user wants to retrieve via the MMS service can then be downloaded via POP3/IMAP4 from the voice 
mailbox to the MMS Relay/Server from where they are delivered to the MMS User Agent. This enables the user to do 
both, retrieve voice messages via today's realtime voice mail services or as an MM. In any case it is expected that the 
voice mailbox is still the owner of the message and as a consequence responsible for the storage. 

As an alternative the MMS interworking with a 2G/3G Voice Mailbox System could be envisaged via an HTTP 
interface as depicted in figure A.5. 
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Figure A.5: Second example of IVIIVIS interaction with 2G/3G Voice IVIailbox based on HTTP 
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Figure A.6 Example of interaction with Internet E-Mail messaging 

In this architecture the server will be an E-Mail server providing post office services which are accessible e.g. via POP3 
[34] or IMAP[35] for Internet E-Mail retrieval in the MMSE or are accessible to the MMS Relay/Server using SMTP. 
The MMS Relay/Server will send messages that are to be transmitted as Internet E-Mail via SMTP. 

In the case of retrieval and sending of MMs from and to the Internet Email service is done via SMTP, the protocol to be 
used on the interface between MMS Relay/Server and the Mail Transfer Agent, MT A/Email Server is identical to the 
one used between different MMS-Relays as specified in subclause 7.7. 
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A.7 Example of interaction with Short IVIessage Service, 
SIVIS 
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Figure A.7: Example of IVIIVIS interaction with SIVISC 

Depending on the SMSC manufacturer the MMS Relay/Server either can be directly connected to the SMSC (as shown 
in figure A.7) or an additional SMS-Gateway has to be added. In the latter case the SMS-GW has to be located between 
the MMS Relay/Server and the SMSC and provides the mapping of one or several SMSC access protocol (mapping 
between MMS Relay/Server SMSC access protocol and operator's existing SMSC access protocol). Currently several 
different SMSC access protocols are defined in 3GPP TR 23.039 [37]. 
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A.8 



Example of Integration with Unified IVIessaging 
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Figure A.8: Example of IVIIUIS integration with UIUIS 

Many carriers are operating or planning to operate Unified Messaging System (UMS) platforms, as well as conform to 
3GPP specifications. Ideally, newly deployed UMS platforms will use MMS as their wireless access User Agents. 
However, newly deployed MMS systems will likely co-exist and integrate with Unified Messaging systems, (UMS), 
voice mail systems (VMS), and email systems. UMS will involve other access methods, such as PC mail access, Web 
browser access, PSTN voice phone access, etc., all of which are outside the scope of 3GPP standardization efforts. 

Some operators may choose to integrate their MMS and UMS services. Even with a complete migration strategy, large 
email systems and VMS systems may require lengthy migration periods during which an integrated operation between 
the 3GPP and legacy systems must occur. Also, some installations will require permanent integrations, where 3GPP 
systems continuously interoperate with a legacy UMS or a legacy VMS. 

The above diagram depicts a possible integrated architecture, building on the previous use cases, where a 3GPP MMS 
Relay/Server interoperates with a UMS that connects to VMS, SMS, fax, and email. 

Access from MMS UA occurs through the MMS Relay/Server. The MMS Relay/Server obtains email, voice, and/or 
fax messages from the UMS. PC clients access through the UM servers which may be integrated with the MMS servers 
by some operators. In this case a unified mailbox will be presented to both MMS users and others who access the 
system via other devices. 

In addition, the UMS Server could possibly stream compressed voice from the VMS, assuming that streaming support 
is available in the servers as well as the clients. It could also establish a CS connection (using for example WTA 
methods to the wireless terminal.) 
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Voice mail and faxes can also originate from a voice/fax gateway server, which exists in both the legacy VMS as well 
as a UMS. Faxes can be sent out to remote fax numbers via the fax gateway. In that case the gateway would convert the 
VM or Fax to VPIM based email messages. 

Access to the VMS and UMS should occur via open standard protocols, such as POP3, IMAP4, WebDAV, T.30, H.323, 
etc. 
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Annex B (informative): IVIIVIS Implementations 

This annex contains examples of protocols which support MMS at the interface between the MMS Relay/Server and the 
MMS User Agent 



B.1 WAP Implementation of MMS 

This informative annex shows how MMS will be implemented using the WAP MMS specifications suite. The WAP 
Forum has created MMS specifications in response to a request from 3GPP to include MMS as part of WAP. At the 
time of writing, the WAP MMS specifications are still under development in the WAP forum. 

It is not expected that implementations of MMS based upon WAP will be realised until the WAP MMS specifications 
are approved and published by the WAP forum. 

WAP provides significant support for MMS, both in direct service specification and in the underlying technologies. 
While the WAP MMS service specification work is new and is therefore unavailable for direct reference, its basic 
approach and limitations are based on WAP documents describing MMS architecture and message encapsulation. This 
should be done based on the underlying WAP technologies that have been published, and can therefore be referenced. 

B.1.1 Protocol Framework 

In reference to subclause 4.3, the protocol framework applied to WAP implementation of MMS on reference point 
MMl is provided in figure B.l. 
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Figure B.l : Protocol Framework applied to WAP implementation of MMS 



B.1 .2 Architectural Support for MMS 



WAP support for MMS is based upon the services of its supporting technology. Therefore, the scope of WAP, as it 
addresses MMS, is as shown in figure B.2. It does not cover activities or network elements beyond those shown and no 
such dependencies or expectations should be inferred or implied. 

Figure B.2 shows an MMS Relay/Server which in the WAP architecture's terminology is referred to as an MMS Server. 
The WAP architecture also refers to the MMS User Agent as an MM Client. These cover equivalent functionalities. 
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Figure B.2: Scope of WAP Support for MMS 

Figure B.2 shows two links. The first, between the wireless MMS User Agent and the WAP Gateway, is where the 
"WAP Stack" is used to provide a common set of services over a variety of wireless bearers. For application oriented 
services, like MMS, the interest is primarily in services offered by WAP Session Protocol (WSP) [23]. 

The second link connects the WAP Gateway and the MMS Relay/Server. In the WAP architecture the MMS 
Relay/Server is considered an Origin Server. These entities are connected over an IP network such as the Internet or a 
local Intranet. HTTP is used for data transfer and data can be originated from either entity. 

End-to-end connectivity, for the MMS application, between the wireless MMS User Agent and the MMS Relay/Server 
is accomplished by sending data over WSP and HTTP. This is accomplished using the WSP/HTTP POST method for 
data originating at the wireless MMS User Agent and by using the WAP Push Access Protocol [24] in the other 
direction. 

The WAP Gateway, which enables the needed interworking, should not modify the data transfer via these transactions. 

The WAP view of MMS is constrained to the interactions between the MMS User Agent and the MMS Relay/Server. It 
makes no representations as to services that are provided to or required of any other network elements. 

B.1 .3 Transaction Flows Supporting IVIIVIS 

NOTE: The WAP MMS work is ongoing and the descriptions in this section are based upon preliminary material 
that is expected to remain stable. 

The WAP MMS work describes the end-to-end transactions that occur between the MMS User Agent and the MMS 
Relay/Server. These transactions accomplish the following services: 

• MMS User Agent originates a Multimedia Message (MM). 

• MMS Relay/Server notification to an MMS User Agent about an available MM. 

• MMS User Agent retrieving an MM. 

• MMS User Agent support for retrieval acknowledgement to MMS Relay/Server. 

• MMS Relay/Server sending dehvery report to MMS User Agent. 

Figure B.3 shows an example transaction flow illustrating a message origination, delivery and delivery report. 
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Figure B.3: Example IVIIVIS Transactional Flow in WAP 

The transactions utilise a variety of transport schemes. For example, the MMS User Agent originates an MM by 
sending a M-Send.req to the MMS Relay/Server by use of a WSP/HTTP POST method. This operation transmits the 
required data from the MMS User Agent to the MMS Relay/Server as well as provides a transactional context for the 
resulting M-Send.conf response. 

The MMS Relay/Server uses WAP PUSH technology to send the M-Notification.ind to the MMS User Agent. This is 
how the MMS User Agent is informed of MMs available for retrieval. Included, as a data component, is the URI of the 
MM that the MMS User Agent is to use for the retrieval. 

The retrieval activity is performed by the MMS User Agent using the WSP/HTTP GET method on the URI provided. 
The fetch of the URI returns the M-retrieve.conf which contains the actual MM to be presented to the user. 

The MMS Relay/Server may request information that would permit to know that the MM was actually received by the 
MMS User Agent. One approach would be for a distinct M- Acknowledge. ind to be passed from the MMS User Agent 
to the MMS Relay/Server. 

The MMS Relay/Server is responsible for supporting an optional delivery report back to the originator MMS User 
Agent. Based upon possible delivery outcomes, the MMS Relay/Server would again utilise WAP PUSH technology to 
inform the MMS User Agent with the M-Delivery.ind message. 



B.1 .4 Terminal Capability Negotiation 



WAP provides a mechanism to inform an origin server, such as the MMS Relay/Server, of the capabilities of the MMS 
User Agent. This is known as User Agent Profile (UAProf) [25]. It provides information about the characteristics of the 
display (e.g. size, color support, bit depth), supported content types and network limitations (e.g. max message size). 

The UAProf data is encoded in an RDF [26] data description language. It is conveyed, possibly indirectly, when the 
MMS User Agent performs a WSP/HTTP operation, such as a GET, to an origin server. It is up to the origin server to 
decode the RDF data, extracting any needed device characteristics, to guide the content generation or filtering operation 
it performs before returning data to the MMS User Agent. 

For MMS, the MMS Relay/Server should be able to utilise the capability information to make adjustments to the 
delivered MM contents. For example, an MMS Relay/Server may delete a message component if the content type was 
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not supported by the terminal. Alternatively, the MMS Relay/Server may adapt an unsupported content type to adjust 
the size, color depth or encoding format. WAP makes no requirements to the handling of this data or of any 
notifications that may be made to the user concerning such adjustments. 



B.1 .5 MMS Message Contents 



The WAP work on MMS is defining a message encapsulation scheme to convey the data between the MMS User Agent 
and the MMS Relay/Server. 

B. 1.5.1 Multimedia Messages 

The MIME multipart technique is standard Internet technique to combine the email body and the attachments together. 
The WAP has a binary equivalent to this, referenced in [23] which can be used to combine multimedia objects in the 
multimedia messages together. This approach shall be used for messages between the MMS Relay/Server and MMS 
User Agent which also include MM components. This includes the message send and retrieve. 

The use of the WAP binary multipart structure allows easy conversion between binary format and the Internet MIME 
multipart. In addition, the binary format allows efficient handling of the message especially in cases when some 
multimedia objects must be taken out of the structure. 

A special, application specific part should contain the MMS header information. This header information is used to 
provide the message type information as well as message-specific information. The proposed content type for this part 
is application/mmsheader and until registration within lANA, the interim content type shall be application/x- 
mmsheader. 

B.I .5.2 Otiner Messages 

Other MMS transactional messages utilise additional PDUs for multimedia message notification, acknowledgements 
and delivery reports. These messages are conveyed with messages that just utilise a content type proposed to be 
application/mmsheader. Until registration within IAN A, the interim content type shall be application/x-mmsheader. 

B.I. 6 MMS Presentation 

The rendering of an MM for a user is the ultimate objective of the MMS. This rendering operation is known as 
presentation. Various types of data may be used to drive the presentation. For example, the MM presentation may be 
based on a WML deck [27] or Synchronised Multimedia Integration Language (SMIL) [28] which includes links to 
other component elements in the multipart message. Other presentation models may include a simple text body with 
image attachments. WAP has not specified any specific requirements on MMS presentations. UAProf [25] content 
negotiation methods should be used for presentation method selection. 

NOTE: In the future, it will be desirable to consider mobile-optimised presentation technologies. For example, 

WAP Forum and W3C have initiated work on a mobile-optimised version of SMIL that would be suitable 
for use in an MMSE. 

B.I .7 MMS Security Model between MMS User Agent and MMS 
Relay/Server 

No MMS-specific requirements are in place within the WAP Forum to support security mechanisms in the transactions 
between the MMS Relay/Server and MMS User Agent. Existing schemes such as WTLS [29] and WIM [30] are 
available and other end-to-end techniques are under development. 
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B.2 IP Based Implementation of MMS for future releases 

This informative annex conceptually demonstrates how IP based MMS would be fulfilled using standard internet 
transport and email protocols. 

It is not expected that fully featured implementations of MMS will be realised using existing IETF protocols until 
additional capabilities are included to support all aspects of MMS. It is anticipated that in due course, these new 
capabilities will be standardised by appropriate standards organisations and will be described in a future release of this 
specification. 

B.2.1 Protocol Framework 

The following figure B.4 is an example of the protocol framework definition for IP Based Implementation of reference 
point MMl in 3GPP MMS. 
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Figure B.4: Example of Protocol Framework Definition for IP Based Implementation in 3GPP MMS 

The protocols of IP Based Implementation would be based on the Internet standards that have been standardized by 
IETF. Wireless profiled TCP, which tunes up the wireless network, would be used for the transmission control protocol. 
What kind of wireless tuned TCP could be used, would be defined by a profile. 

The Transfer Protocol between MMS User Agent and MMS Relay/Server would be SMTP, POP3, IMAP4, HTTP etc., 
depending on the services. 

The notification services and the other needed services between MMS User Agent and MMS Relay/Server would be 
supported by using the appropriate protocol. 

NOTE: The appropriate protocol would be used as soon as the standardization would have been completed. 

B.2.2 Architectural Support for MMS 

The following figure B.5 is an example of the architecture definition for IP Based Implementation in 3GPP MMS. 
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Figure B.5: Architectural example of IP Based Implementation for 3GPP MMS 



The communication between a terminal and the IP Based Gateway would use the appropriate IP Based protocol like 
SMTP, POPS, IMAP4, HTTP, etc. on wireless profiled TCP to provide services. 

The communication between the IP Based Gateway and the MMS Relay/Server would use the appropriate IP Based 
protocol like SMTP, POP3, IMAP4, HTTP, etc. on TCP to provide services. Wireless profiled TCP would be translated 
to normal TCP in the IP Based Gateway. 

B.2.3 Transaction Flows Supporting IVIIVIS 

The following figure B.6 is an example of transaction flows for IP Based Implementation in 3GPP MMS. 
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Figure B.6: Example of transaction flows for IP Based Implementation in 3GPP MMS 



For example; 

1. MMS User Agent (Originator) would send a Multimedia Message (MM) by sending MMl_Submit.REQ to MMS 
Relay/Server by use of a SMTP or HTTP POST method. There could be MMl_Submit.RES response by use of 
HTTP. 

2. MMS Relay/Server (Originator) would forward the MM sending MM4_forward.REQ to MMS Relay/Server 
(Recipient) by use of SMTP. There could be MM4_forward.RES response by use of HTTP. 

3. MMS Relay/Server (Recipient) would use IP based PUSH technology to send MMl_notification.REQ to MMS 
User Agent (Recipient) by use of HTTP POST method or the other appropriate way. There could be 
MMl_notification.RES response by use of HTTP. 

4. The MMS Relay/Server might request information that would permit to know that the MM was actually received 
by the MMS User Agent. One approach would be sending MMl_acknowledgement.REQ from the MMS User 
Agent to the MMS Relay/Server. 

5. As an option, MMS Relay/Server (Recipient) might forward a message by using MM4_forward_report.REQ to 
MMS Relay/Server (Originator) by using SMTP or HTTP. There could be MM4_forward_report.RES response by 
use of SMTP or HTTP. 

6. The MMS Relay/Server is responsible for supporting an optional delivery report back to the originator MMS User 
Agent. Based upon possible delivery outcomes, the MMS Relay/Server would again utilize IP based PUSH 
technology to inform the MMS User Agent with the MMl_delivery_report.REQ message. 
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B.2.4 Terminal Capability Negotiation 

The Terminal Capability Negotiation would be based on the Internet standard (e.g. CC/PP). 

B.2.5 IVIIVIS IVIessage Contents 

The MMS Message Contents would be video mail, audio mail, image mail, text mail and so on. 

B.2.5. 1 IVIultimedia IVIessages 

The Multimedia Messages would be based on RFC822 (Standard for the format of ARPA Internet text messages) and 
MIME (Multipurpose Internet Mail Extensions, RFC 2045 - 2049). 

B.2.6 IVIIVIS Presentation 

The MMS Presentation would be based on MIME (Multipurpose Internet Mail Extensions, RFC 2045 - 2049) and 
Internet standard. 

B.2.7 MMS Security Model between MMS User Agent and 

MMS Relay/Server 

What kind of security mechanism could be used, would be defined by a profile. 
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Annex C (informative): Call Data Records 

This annex describes information of MMs/abstract messages which may be required for inclusion into Call Data 
Records (CDR's) for MMS for the purpose of Billing and Traceability. 

This list of information elements is not complete but includes: 

MMS-specific message-ID 

Recipient address(es) 

Sender address 

Message size (sent / received) 

Identification if a message has been sent to a pre-defined group 

Time stamp ( including timezone ): for submission time, earliest delivery time and time of expiry 

Duration of transmission (e.g. for streaming purposes) 

Duration of storage (in the MMS server) 

Type of message: (e.g. notification, message MM, delivery report, read-reply) 

Bearer type used 

Content information(e.g. audio, picture, video, text,) 

Message class (e.g. advertisement/informational) 

Delivery Report Request 

Read Reply Request 

Charging Indicator ( e.g. Pre paid charging. Reply charging. Reverse charging. Third party financed ) 

MM Status (e.g. delivered, abandoned, time expired, delivery pending). 

Indication of forwarding 
This information shall be time-stamped. 

The following information elements at least will be considered for the future. 
A specific class / type for MMS used for the Instant Messaging functionality 
Conversion of type and media 
Security level used 
Priority/QoS 
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Annex D (informative): iVIiVIS principles 
D.1 Sending of IVIIVIs 

On sending an MM to an external server the MMS Relay/Server: 

should map as many fields as possible to corresponding fields of the message format or protocol of the external 
server while suppressing MMS-only relevant fields (e.g. MMS-version) or sensitive fields (e.g. originator Address 
when address hiding is requested) and fields that cannot be mapped (e.g. Content-type in case fax gateway). 

In the case the external server uses RFC 822 formatted messages the mapping should be according to the mapping 
on MM4 under consideration of the above mentioned constraints. 

May add relevant fields that cannot be mapped to fields of the message format or protocol of the external server to 
the content body of the message if suitable (e.g. Print Content-Type, Priority, etc. on fax). 

should convert the content itself into the appropriate format used by the external server (e.g. WAV(G.723) 
attachment to AMR attachment for voice mail system) 



D.2 Receiving of messages 



On receiving a message from an external server the MMS Relay/Server should be able to handle the following on 
MM3: 

The external server may send a message with RFC 822 formatted header and a body with encapsulated message 
type of the external server (e.g. e-mail with attachment application/sms). In that case the MMS Relay/Server should 
map as many fields of the RFC 822 header to the corresponding header fields of an MM. Additionally the MMS 
Relay/Server may be able to copy MMS relevant information from the MIME encapsulated body and map them to 
the corresponding header fields and body of an MM. The attachment itself should be forwarded unaltered as 
attachment of the generated MM to the recipient. 

The MMS Relay/Server should be able to interpret MMS specific fields in the RFC 822 header of a message from 
an external server (e.g. voice mail can specify expiry date) 

The external server may send a message with regular RFC 822 formatted header and MIME encapsulated 
attachments which may comprise content and/or profile information (e.g. VPIM multipart/voice-message). The 
MMS Relay/Server should be able to map as many fields of the RFC 822 header to the corresponding header fields 
of an MM. Additionally in the case the attachments contain some message profile information the MMS 
Relay/Server should be able to map those to the corresponding header fields of an MM. The attachments / parts of 
the attachments with message content may be converted to another media type or format subject to the capabilities 
of the MMS User Agent. In most cases the attachments might be forwarded unaltered to the recipient. 

The external server may send a message with a format different from RFC 822. In this case the MMS Relay/Server 
should be able to extract as many information from the external message format and protocol and map them to 
corresponding fields of the MM header. The content of the message from the external server should be mapped to 
an appropriate MIME type/subtype and attached to the MM. (e.g. SMS via 3GPP TR 23.039 -> MM with 
text/plain) 



£75/ 



3GPP TS 23.140 version 4.3.0 Release 4 



72 



ETSI TS 123 140 V4.3.0 (2001-06) 



Annex E (informative): Use cases for Reply-Charging 

The following detailed example use case of reply-charging describes the case when MMS User Agent A and MMS User 
Agent B belong to the same MMSE. MMS User Agent A is the sender of the reply-charged MM and MMS User Agent 
B is the recipient of the reply-charged MM. 




MMS A 

UA A 




MMS 
UAB 



1 . User A produces an MM and marks it "reply-charged" before it is submitted to the MMS Relay/Server. The MMS 
Relay/Server notes that user A is willing to pay for a reply-MM to this particular MM and notes the message-ID of 
the original MM and the originator's limitations. 

2. The MM is retrieved by user B in accordance to the user profile of user B. This might imply charges for user B 
when retrieving the MM. User B retrieves the original MM and discovers that the first reply to this message (that is 
accepted by the Service Provider) will be paid by user A. 

3. User B creates an answer, the MMS User Agent B marks it as a reply-MM and submits it on to the MMS 
Relay/Server. The MMS Relay /Server identifies this MM as a reply to the original MM and checks the originator's 
limitations. If the MMS Relay/Server accepts the reply the reference set before (as described in transaction 1) is 
deleted. User A is billed for transaction 3. 

4. User A retrieves the reply-MM and eventually is billed for transaction 4. 

The other use case of reply-charging where MMS User Agent A and MMS User Agent B belong to different MMS 
Service Providers is for future elaboration. 

The use case of reply-charging where the originator MMS User Agent is actually the MMS VAS Application (using 
MM7 reference point) behaves in the same way as the use case of two MMS User Agents in the same MMSE. 
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Annex F (informative): Change history 
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